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ABSTRACT 



This report describes the first phase of an 
ongoing library automation project at Stanford 
University. Project BALLOTS seeks to automate the 
acquisition and cataloging functions of a large library 
using an on-line time-sharing computer. The main 
objectives are to ..cpntxoJ rising .Jtftch.nl cal processing 
costs ami at the same time to provide improved levels 
crf'servi ce. Phase 1 produced a prototype system that 
operated in the library using typewriter terminals. 

Data preparation and data control units were 
established; regular library staff were trained in 
on-line input and searching. After a nine-month period 
of operation, the entire system was evaluated. The 
requirements of a production library automation system 
were then defined. 

Findings are presented on shared facilities, 
economy and file integrity, the performance 
of on-line searching, terminal performance, staff and 
resource commitments, transferability, and the human 
aspects of system development. Recommendations are 
presented with respect to feasibility, economic 
factors, management, staffing, documentation, terminal 
equipment, and national planning. 
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PREFACE 



(I 

' Project BALLOTS is an on-going l ibrary automation 

development effort at Stanford University. Phasel covers the 
jj period of prototype system development and operation as well as 

([ the first months of production system development. Since its 

inception, the project has benefited from the advice and 
I i assistance of many people. Although only a few of them can be 

j mentioned in this preface, our appreciation goes to all who 

contributed during a long and complex development process. 

jj Special acknowledgment is extended to the following 

persons and groups connected with the project: 

j( Paul Armer, former Director of the Stanford 

U. Computation Center; 



f-i Roderic M. Fredrickson, former head of the Campus 

IJ Facility (IBM 360/67) of the Stanford Computation 

Center; 

|| Ralph Hansen, Chief Librarian of the Acquisition 

Department; 

U Jennette Hitchcock, Chief Librarian of the Catalog 

(J Department; 



Prof. William F. Miller, former Vice President for 
Research (now Provost of the University); 




Prof. Edwin B. Parker, Department of Communication; 

David C. Weber, Director of University Libraries; 

Members of the BALLOTS External Advisory Committee 
(see section 2.2 for a list of members). 

Many other persons in the university commun i ty-especi a 1 1 y in the 
Libraries and the Computation Center-contributed thousands of 
hours . 
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The achievment of the prototype system is a result of 
the work done by the entire Project BALLOTS staff/ plus that done 
by members of the Project SPIRES staff in areas of common 
software development. It is a pleasure to acknowledge the work 
of William Riddle (now of the University of Michigan Department 
of Communications)/ who designed the on-line executive program/ 
and of James Marsheck/ who played a major role In designing the 
search facility. Wayne Davison/ Diana Delanoy, and Jerry West 
made significant contributions in the library systems analysis 
for the prototype system. Glee Cady and Carol Kayser were 
largely responsible for the smooth functioning of the Data 
Preparation and Data Control units in the library. Pam Dempsey 
of the Catalog Department and Fred Lynden of the Acquistion 
Department contributed many hours and their detailed knowledge of 
library operations. 

This report has been read and commented on by a special 
technical subcommittee of the BALLOTS External Advisory 
Committee/ consisting of Fred Bellomy/ Manager/ University of 
California Library System Development Program; Grover Burgis/ 
Director/ Research and Planning Branch/ national Library of 
Canada; Audrey Grosch/ Head/ Systems Office, University of 
Minnesota Library; John P. Kennedy/ Data Processing Librarian/ 
Price Gilbert Memorial Library/ Georgia Institute of Technology; 
Fredrick Kilgour/ Director/ Ohio College Library Center; and 
David Weisbrod/ Head/ Development Department/ Yale University 
Library. Particular appreciation is extended to Donald V. Black 
of System Development Corporation/ who chairs this subcommittee. 
Mr. Black's extensive and constructive comments and the example 
of his excellent report on a sister project (Project LISTS <4>) 
contributed immeasurably to the improvement of this report. 
Neither Mr. Black nor any of the subcommittee is responsible for 
errors or inadequacies in this report. 

We especially acknowledge the capable assistance of 
Jennifer Hartzel 1 in organizing/ editing/ and producing this 
report. The BALLOTS staff has been ably supported in its work by 
the following secretaries: Marlene Amiot/ Sandra Anderson/ and 
Charla Meyer. , 

The complexity of the BALLOTS Project has been estimated 
at twenty to fifty times greater than the development effort that 
Stanford applied to the computer-produced lie 1 ar Undergraduate 
Library Book Catalog Project--an effort that produced several 
thick volumes of documentation <13>. This report/ therefore/ can 
only hope to cover the highlights of a large and multifaceted 
development effort. The reader will not find in this document 
extensive flow charts outlining specific design modules/ or 
program listings. Much o'. the very detailed design work/ 
particularly that relating to the on-line facilities/ has been 
included in quarterly reports to the Office of Education. The 
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substantive reports have been made avail 
and are referred to in the text and refs 
covers the period from June 1967 to June 



able in the ERIC system 
jrencss. This report 
s 1970. 



This final Report follows the outline format prescribed 
for U. S. Office of Education research reports. Chapter 1.0 
summarizes the recommendations of the report/ describes the 
problem context and background/ and stakes the scope and goals Of 
the system. Chapter 2,0 describes the <|eve 1 opment and operation 
of the BALLOTS I prototype system. Chapter 3.0 discusses some 
findings based on the operation and evaljuaLion of BALLOTS I. 
Chapter 4.0 discusses the recommendations that 
can be made at this stage in the development of the BALLOTS 
system. 
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1.0 INTRODUCTION 

Project BALLOTS (Bibliographic Automation of Large 
Library Operations using a Time-sharing System) is directed 
toward maximizing the contribution of the large research library 
to ■ un i vers i ty education. Increasing costs of operation and the 
limitations of a manual file system inhibit the library's 
responsiveness to the changing information requirements of higher 
education <33>. The BALLOTS approach is to provide technological 
assistance to the library in the form of an on-line# production# 
bibliographic processing system <27>. This system must be 
available on a daily basis# initially to support technical 
processing operations but with the ability to extend direct 
service to public users. The project is divided into two major 
phases: BALLOTS I# research and prototype development# completed 
at the end of calendar 1969# and BALLOTS II# production system 
development# the present ongoing activity. 

1.1 Summary of Recommendations 

l 

To assist the reader in evaluating the conclusions 
reached in the prototype development phase# a summary of 
recommendations is presented first. It is important to bear in 
mind that the project is not yet completed and these 
recommendations are in the nature of an interim report. 
Nevertheless# it is our belief that they represent reasonable, 
conclusions based on three years' experience wi th on-line library 
system development. Each recommendation is discussed more fully 
in Chapter 4.0. 

1. FEASIBILITY RECOMMENDATION 

A library considering on-line system development should 
conduct feasibility studies that make clear the advantages and 
disadvantages of in-house development# contracted development# 
and a mixture of both. 

2. ECONOMIC RECOMMENDATION 

At the present time, the cost of developing large# 
on-line library systems must be supported by funding outside the 
library's operating budget. 

3. MANAGEMENT RECOMMENDATION 

On-line system development should have professional 
computer management# under the policy direction of the 
library and subject to the library's continuing review and 
approval . 
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4. STAFFING RECOMMENDATION 



Libraries considering on-line systems should secure or 
contract with technical personnel having on-line experience/ 
preferably in some kind of bibliographic/retrieval application. 

5. DOCUMENTATION RECOMMENDATION 

Documentation is a primary development task/ and funds/ 
specialized personnel/ and formal management commitment are needed 
for its accomplishment. 

6. EQUIPMENT RECOMMENDATION 

Specifications for video (CRT) terminal equipment 
to support on-line library operations should be brought to the 
attention of manufacturers. 

7. NATIONAL PLANNING RECOMMENDATION 

The development of large/ on-line library systems 
should be planned and implemented on a regional basis. 

1.2 The Problem Context 

Well-known to librarians but generally hidden from the 
layman's view is the vast "iceberg" of internal technical 
processing activities in the library. Large and complex files 
are subject to intensive operations: record creation, deletion, 

update, sorting, filing, searching, and selective output. 

Material comes to the library from every country of the world and 
in every language; foreign books and documents are printed wi th 
special symbols and graphic characters whose requirements range 
far beyond those of common English or of roman alphabet notation. 
The Library of Congress's own requirements for graphic characters 
call for 175 unique character representations for roman 
alphabet material alone, a number doubtless far beyond the 
requirements of many other libraries, but one that: indicates 
the scope of the problem of inputting, storing, processing, and 
outputting bibliographic records. 

The number of files in a library may range from a few 
dozen in small and medium-sized libraries to hundreds in 
university and research libraries. The Library of Congress is 
known to employ over 1,200 files in maintaining its worldwide 
bibliographical services. University and research libraries 
maintain centralized union catalogs that often contain five to 
ten million cards or more. Institutions that have many 
discipline-oriented departmental libraries must also maintain 
catalogs and shelf lists for each of these unit or branch 
libraries. 



5 



11 



The number of transactions Involving library files can 
be staggering. Those involving certain files in a large library 
can easily exceed several hundred per hour. A large public 
library system may record from a quarter-million to a million 
loan transactions per month. Each loan represents at minimum two 
transactions in the file, one for charging an item and one for 
discharging it. To these must be added the innumerable requests 
for reserving books held by other borrowers, identifying overdue 
items, recalling items, notifying requesters, and the like. 

Large as the circulation transaction volume is in a 
typical library, circulation files share a singular 
character i s t i c : the i r bibliographic content is relatively small 
and changes very little. In library technical processing, 
however, the opposite is the case: bibliographic content is 

extensive, complex, changing, and often only partially or 
inaccurately known. How is it possible to conceive of 
bibliographic information that is known only partially or 
inaccurately? The vagaries of the international book trade and 
the complexities of the publishing industry commonly introduce 
unknowns into the library data base at the initial point of a 
record's entry into library files. Publishers change the titles 
of books previously announced in a prospectus. The title of an 
unchanged or slightly altered reprint is changed without notice 
to the public. A list of multiple authors is rearranged owing to 
the death of a contributor or to the resignation of a joint 
author. Publications of a work in the same language but In 
different countries are given different titles, and may even vary 
slightly in content. Through personal correspondence, 
conferences and meetings, and announcements in journals, faculty 
members learn of new works in press and initiate book requests 
based on incomplete information, incorrect spel 1 i ngs,. or faulty 
recollection. Students, faculty, and librarians seek out works 
from published citations that are ambiguous, incomplete, or 
erroneous. 



Additions to and maintenance of the card catalog rival 
the activity in the circulation system. During the past five 
years the Stanford Libraries have added nearly one million cards 
to the main card catalog. The effective rate of adding new 
records to all Stanford catalogs approximates 1,000 records per 
work day. It would be a sufficiently complex problem to deal 
with these record and file characteristics in the English 
language. But the large university library typically takes in 
about 50 percent of its material in foreign languages, and in 
large metropolitan centers, such as Mew York and San Francisco, 
public libraries must acquire and process large amounts of 
foreign language materials in order to accommodate the needs of 
special ethnic or linguistic constituencies. Obtaining staff who 
can read, spell, and understand a multiplicity of languages is 
essential to proper maintenance of large bibliographic files; but 
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even then the prevalence of transcription and filing errors In 
manual systems is a significant cause of Inefficiency in the 
large 1 ibrary. 

Typically/ the staff assigned to file creation/ 
searching./ and maintenance are library assistants working under 
the supervision of librarians. In the academic community/ 
student spouses constitute a ready source of assistants. Unfor- 
tunately, the work is routine, and those best qualified to 
perform it become bored quickly. Furthermore, here as in other 
areas the economic constraints of university libraries prevent 
effective wage competition with local business and industry. The 
result is excessive staff turnover, leaving the librarian with 
poorly done clerical work, too much revision of clerical work, 
and wastage of a high percentage of professional time in 
continually training new staff. 

Another problem is vocabulary and terminology. It is 
not enough for the large library to furnish access to its 
bibliographic files by author and title; users who do not know 
the writers in a specific f i el d- -espec i a 1 1 y students who are 
beginning their academic careers--must be given subject access to 
the library's collections. Yet subject terminology is being 
revised continually in the field, especially as a result of the 
coalescence of many disciplines, such as biophysics, medical 
electronics, aerospace medicine, and the like. Although not 
physically impossible, it is economically and managerially 
impossible to maintain current subject headings in a large manual 
system that includes all subjects and all major languages, where 
the collections range in time from the earliest printed materials 
to present-day works; and where content has no chronological 
limit. 



Evidence of the decreasing effectiveness of manual 
technical processing may be found in the increasing unit cost of 
book processing during a period when teaching, research, enroll- 
ments, and publications all increased significantly <34>. Where the 
traditional purchase-cost - labor-cost ratio for book purchase 
and processing was practically one for one for many years, it now 
appears we are reaching the point where it regularly costs more 
to process a book than to buy it. Inflation as it affects 
salary levels and book prices is a factor in the overall increase 
but the affect on salaries seems to be greater than on prices. 

Figure 1, a table of book and technical processing expenditures 
during a recent six-year period at Stanford, illustrates this. 
Overmyer <20, p. 272> in a critical review of library automation 
states : 



Even those who are not very enthusiastic about 
automation admit that, assuming no more than the 
present rate of growth, many libraries will not be 
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1. Technical 
Processing Costs 

Resources Develop- 
ment Program 
Acqu i s i tion 
Div. (3 802* 

Catalog Div @ 1002 

Total 

Percentage of 

68/69 level 

2. Book Expenditures 
( excl . binding a 
periodicals) 

3 . Nos . 1 & 2 
totaled 



1963/64 1964/65 



$ 23/089 


$ 43/998 


89/000 

119/767 


101/000 

161/081 


$231/ 856 


$306/079 


272 


352 


351/000 


394/000 


582/856 


700/079 



43/57 43/57 

23/ 206 . 24/142 

$10 $12.70 



1965/66 


1966/67 




{ 


$ 54/592 


$ 55/841 


120/000 

256/986 


150/000 

325/918 


$431/578 


$531, 759 


502 


62 2 


487/000 


617,278 


918/578 


1,149/ 037 


472 


46 2, 


51/49 


53/47 


31/469 


58,399 


$13.75 


$9.10' 



4. Tech. Proc. Costs (No. 

1) as a percentage of 
total costs (No. 5) 402 432 



5. Tech. Proc. Staff vs. 
Ref. Staff (ratio 

of percentages) 

6. Titles Cataloged 
(Univ. Libraries 
only) 

7. Unit Proc. Costs 
(Nos. 1-6) 



* 202 of Acquisition Division activity relates to binding and sen 

per i od i ca 1 s--both excluded from these figures. 

** The Library added 22/000 microforms en bloc in 1966/67/ 

which resulted in an apparent lowering of preparation costs 
for the year's workload. 
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1964/65 
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1967/68 


; Costs 












•lop- 


$ 23,089 


$ 43,998 


$ 54,592 


$ 55,841 


$ 64,680 


100? 


89,000 

119,767 


101,000 

161,081 


120,000 

256,986 


150,000 

325,918 


208, 500 
459,926 




$231,856 


$306,079 


$431,578 


$531, 759 


$733, 106 




27? 


35? 


50? 


62? 


85? 


idi tures 
iding & 
's ) 


351,000 


394,000 


487,000 


617,278 


669,590 


> 


582,856 


700,079 


918, 578 1 


, 149,037 


1,402,696 


:. Costs (No. 
jercentage of 
:s (No. 3) 40? 


43? 


47? 




52? 


:. Staff 
: (ratio 
:ages ) 


vs. 

43/57 


43/57 


51/49 


53/47 


57/43 


:aloged 
>rar ies 


23,2:06 


24,142 


31,469 


58, 399 


53,689 


Costs 


$10 


$12.70 


$13.75 


$9.10** $13.60 


i i s i t ion 
i — both 
f added 


Division activity relates to binding 
excluded from these figures. 

22,000 microforms en bloc in 1966/67, 


and service to 



t or1 • n an apparent lowering of preparation costs 

ir ERJC rkload ‘ 



1968/69 

$ 98,600 

256.000 
503, 000 

$857, 600 

100 ? 

720. 000 
1, 577,600 

55? 

60/40 

57,990 

$14.80 
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able to handle their day-to-day processing by manual 

methods and will be forced to look for alternatives. 

1.3 Background Review 

.In 1967/ the University Libraries and the Stanford 
Institute for Communication Research began research projects with 
funds from the Office of Education (for BALLOTS) and the National 
Science Foundation (for SPIRES). In 1968/ the two projects came 
under the policy direction of the SPIRES/BALLOTS Executive 
Committee; the shared perspective and close collaboration of the 
projects were thus formalized. 

Stanford University was an appropriate setting in which 
to initiate research and development in bibliographic retrieval. 

A strong interest was taken in automation in all areas of the 
Stanford University Libraries/ especially by Che Libraries' 
Associate Director (now Director)/ David C. Weber/ and the 
Assistant Director for Bibliographic Operations/ Allen B. Veaner. 
During the period from 1964 to 1966/ the library had achieved a 
remarkably successful computer-produced book catalog for the J. 
Henry Meyer (Undergraduate) Library. Edwin B. Parker and his 
colleagues at the Institute for Communication Research were even 
then applying to computer systems the behaviorial science 
analysis that they and others had applied already to print/ film/ 
and television media. The Stanford Campus Facility had an IBM 
360 model 67 computer/ a locally developed time-sharing system/ 
and a first-rate programming staff associated with one of the 
nation's leading computer science departments. A close working 
relationship between the University Libraries/ the Computation 
Center/ and the Institute for Communication Research made a firm 
foundation for research and development. 

In the library/ an analysis and design group worked 
closely with the library staff in studying library processes and 
defining requirements. The combined project software development 
group applied themselves to writing programs necessary for 
bibliographic retrieval. This joint effort created a prototype 
system that could be used in the Main Library and by Stanford 
faculty and students/ primarily high-energy physicists. 

In early 1969/ two prototype applications were activated 
using the jointly developed systems software: an acquisition 
system (BALLOTS I) was established in the Main Library, and a 
bibliographic retrieval system (SPIRES I) was established for a 
group of high-energy physicists. 

Centralized management of library input was handled by 
two newly created units. Data Preparation and Data Control. 
Several terminals were installed in the Main Library for on-line 
searching, and a terminal was placed in the Physics Library. An 
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on-line In Process File was created, consisting of 30 percent of 
the roman-alphabet acquisition material ordered by the ltbrary. 

A specially trained staff performed on-line searching daily 
during regular library hours. This prototype acqulsiton system 
operated during most of 1969, demonstrating the technical 
feasibility of the combined project goals. It was studied and 
evaluated by the library systems and programming staffs, who 
reviewed the human, economic, and technical requirements of a. 
library bibliographic retrieval system. 

At the Stanford Linear Accelerator Center (SLAC) 

Library, a file of preprints in high-energy physics was created 
through SPIRES I <24>. This file is still active; records of new 
preprints are added weekly, and a note is made of any preprint 
that is published. Input is via an IBM 2741 typewriter terminal 
in the SLAC Library. Regular library staff at SLAC handle inputs 
and updating. Searching can be done by author, title, date, and 
citation. The preprint file contains approximately 9,000 
documents, including all the high-energy-physics preprints 
received in the SLAC Library from March 1968 to the present. 
"Preprints in Particles and Fields," a weekly published listing of 
preprints, also is produced from SPIRES I. 

1.4 Scope of the Project 

A recent survey of library automation lists over 250 
projects or existing systems <16>. Some universities wi th major 
research libraries have not chosen an on-line approach <12, 21>. 

In the belief that flexible, comprehensive, and long-range 
economical computer support for the library can be attained by 
on-line systems, Stanford has chosen to develop a production 
•system for acquisition and cataloging that is extendable to other 
library operations (e.g. circulation). A prototype system was 
the basis for exploring problems of on-line development and 
operation. The production system must be available daily throughout 
library working hours for input, update and search of on-line 
files and output of needed ordering and cataloging documents. It 
carries most of the processing load in the library functions it 
supports. Reliability, rapid recovery, and cost effectiveness 
are an inherent part of production operations. 

t 

Corbato <8> has identified the attempt to make more than 
one major advance at a time as one of the major problems of large 
system development. A conscious attempt was made to delimit the 
BALLOTS project by carefully excluding certain problems that were 
not considered researchable within the available time and 
resources. Among the problems BALLOTS decided not to attack 
were: (1) Input, storage, and output of non-roman alphabet 
records; (2) provision of extended graphic character 
representation for special characters and diacritical marks; (3) 
data compression; (4) searching aids for "near-hit" search 
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rgurrien t s : and (5) use of very advanced techniques for handling 
bibliographic data that are still In the developmental stages, 
such as optical character recognition. 

> 

Even with focused effort the time for this project was 
estimated at three to five years. Any hardware used by the 
project would have to have an interface with the IBM 360/67 and 
be supported by the Computation Center. To promote 
t ransf e rab i 1 i ty , it was decided that all the hardware used would 
be off-the-shelf equipment available as regular production items 
from established manufacturers. 

1.5 System Goals 

\ ! 

The problem under 'Investigation is the technical, 
economic, and organ 1 za t i ona 1 V 'feas i b i 1 i ty of using a time-sharing 
system to service the file transaction functions of 
a large library. Technical feasibility means accomplishing 
the task with existing technology and software. Economic 
feasibility means accomplishing the task without increasing the 
library's budget beyond the savings that might result from the 
system within a reasonable payoff period (five to seven years). 
Organizational feasibility means accomplishing the task with 
existing library staff and with a minimum disruption to the 
library's regular activities. 

1.5.1 Prototype goals 

The implementation of the prototype system was confined 
to the technical processing activities of acquisition and 
cataloging, areas in which workloads have increased strikingly at 
all university libraries in the past ten years <11>. Certain 
major goals vjere selected for the prototype system. 

1. Overcoming the geographic limitations 

of manual files by providing access to machine- 
readable files at any point where a computer 
terminal could be connected. 

i 

2. Lessening the effects of staff turnover on the 
consumption of professional time devoted to training. 

3. Greatly Increasing the sophistication of bibliographic 
searching by permitting users to combine multiple 
access points — such as author, title, and date — into a 
single search argument. 

4. Reducing the amount of staff time--and the errors-- 
associated with the maintenance of manual files. 
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5. Promoting the use of centrally produced, machine- 
readable files, such as MARC and ERIC data bases. 

6. Generalizing the system design sufficiently to 
facilitate its export to other institutions with 
problems of similar scope and equivalent resources. 

It is a fair question to what extent these goals were 
reached. In retrospect it appears that attempting to reach goals 
two and five with the prototype system was overamb i t i ous . 

Although it is likely that these goals can be achieved, the 
evidence from BALLOTS I is not conclusive. Goals one, three, and 
four were reached. Goal six was only partially attained (this is 
the subject of further discussion in section 3.6 of chapter 3.0). 
One outcome of BALLOTS I was a clear conception of the goals of 
BALLOTS as a production system, as well as of the goal of 
facilities to be shared with SPIRES. The following subsection 
describes the goals for BALLOTS II, for shared facilities, and, 
in the interests of completeness, of SPIRES II. 

1.5.2 Production goals 

In the research phase, BALLOTS collaborated with SPIRES 
(Stanford Physics Information REtrieval System), a project funded 
by the National Science Foundation. The two projects have 
hardware and software in common; these "shared facilities" are 
developed jointly. This has resulted in the maximum use of 
scarce and highly skilled system programming personnel and in a 
valuable cross-fertilization of ideas between related 
applications. The project goals for library automation 
(BALLOTS) and for generalized information storage and retrieval 
(SPIRES) are interrelated. The goal of shared f ac i 1 i t i es--both 
hardware and sof tware--furthers and serves both of the intimately 
related projects. 

Basically, BALLOTS is a transaction-oriented system that 
creates, adds, deletes, and modifies sets of frequently used 
records. BALLOTS thus supports the logistical aspects of biblio- 
graphic data processing, i.e. library activities, carried out 1 
under time constraints, that concern the flow of bibliographic 
information and library materials. This flow extends from among 
the technical processing staff to staff members, such as 
reference and circulation librarians, who interact directly with 
library users. SPIRES is a search- and retr i eva 1 -or i ented system 
that provides access to bibliographic and other records created 
through transactions (i.e. BALLOTS activity) or furnished from 
outside sources (e.g., MARC). Librarians can use BALLOTS to 
create and manage their bibliographic files; they can also use 
SPIRES, to support the information retrieval aspects of their 
work. Non-librarians can search BALLOTS files to 
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support their individual information-gathering activities. 
Eachsystem is available to the user at a terminal without his 
needing to know which he is actually employing. This feature is 
exceedingly valuable because it means the user is offered a 
unified record management and retrieval system; he is not re- 
quired to switch from one system to another. 

BALLOTS 



The university library is a complex combination of 
people, machines, and records that organize and open up the major 
bibliographic resources of the university to students and 
faculty. It reflects the needs and priorities of a changing 
university environment. As the major information center of a 
large academic institution, it must respond rapidly, effectively, 
and economically to the university community <36>. The university 
library is also part of a larger network of information sources 
that includes other research libraries, the Library of Congress, 
and specialized agencies of information storage and 
dissemination, such as professional societies and national 
abstracting and indexing services. 

The essential goals of BALLOTS will be obtained in a 
combined manua 1 -automated system that is: 

USER RESPONSIVE. It adapts to the changing 
bibliographic requirements of diverse user 
groups in the university, and extends faster 
and more extensive bibliographic services into 
all campus buildings with appropriate terminals. 

COST COMPETITIVE. It provides fast, efficient 
internal processing of increasing volumes of 
transactions at reduced unit costs. 

GENERAL I ZABLE . It is not just an attempt to 
automate portions of the existing manual system; 

It can be separated from existing procedural, 
organizational, or physical settings. It is 
based on the actual operating requirements of 
library processing. 

PERFORMANCE ORIENTED. It provides the library 
and the university administration w i t h data that 
are useful for measuring Internal processing 
performance and user satisfaction. 

FLEXIBLE. It has the capability to expand in 
order to embrace a broader range of services and 
a wider group of users. Service via terminals 
will be available throughout the campus and to 
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any non-Stanford user who has an appropriate 
terminal. The system will be able to link up with 
and serve other information systems, and effective- 
ly use nati.onal data sources such as MARC tapes. 

.These goals have been formulated into specific 
requirements that will, among other things, minimize manual 
typing, sorting, and filing; eliminate many clerical tasks now 
being performed by professionals; increase self-service 
efficiency; and provide mechanisms for recording the user's 
suggestions and reactions. The effect of these computer 
capabilities will be to reduce sharply the errors associated with 
manual sorting, typing, proofing, and hand transcribing; to speed 
the flow of material through library processing; to aid book 
selection by providing fast access to central automated files; 
and to enable librarians to advise an inquiring patron of tne 
exact status of a work before it is cataloged and placed on the 
shelf. In summary, responsiveness to library users, efficient 
operation, generality, performance monitoring, and flexibility 
for future improvements are the essential goals of library 
automat i on . 

SPIRES 



The SPIRES generalized information storage and retrieval 
system will support the research and teaching activities of the 
library, faculty, students, and staff. Each user will be able to 
define his requirements In a way that automatically tailors the 
system response to fit his individual needs. The creation of 
such a system is a major effort, involving the study of users, 
source data, record structures, and file organization, as well as 
considerable experimentation with facilities. The SPIRES system 
will be characterized by flexibility, generality, and ease of 
use. The goals of SPIRES will be attained in a system that 
has the fol lowing- character 1st ics. 

DATA SOURCE AND CONTENT. It will store biblio- 
graphic, scientific, administrative, and other 
records in machine-readable form. Collections 
will range from large public files, converted 
from centrally produced machine-readable data, 
to medium-small files, created from user-generated 
input— e.g., faculty-student files or data created 
by the administration of the university. 

SEARCH FACILITIES. It will provide for searching 
files interactively (on-line) via a computer 
terminal; on a batch basis, by grouping requests 
and submitting them on a regular schedule; and on 
a standing request basis. In 'which a search query 
is routinely passed against certain files at 
specified intervals. 
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FEEDBACK. It will provide reports on how 
frequently various system components are used. 

These will Include statistical analyses of user 
problems and system errors. 

RECORD MODIFICATION. It will provide update and 
editing capabilities on a batch basis or on-l.ine; 
options for update will come at the level of 
record, data element, and character string within 
a data element. 

COST AND CUSTOMERS. It will provide services at a 
cost sufficiently low to enable a wide range of 
customers to cost-justify their use of the system. 
The variety of services should be sufficiently 
great to encourage a growing body of users. A 
range of services at various cost levels must be 
offered to permit users to select the service that 
meets their needs within their financial resources. 

BALLOTS AMD SPIRES SHARED FACILITIES 

Shared facilities are the hardware and software designed 
to provide concurrent service to both BALLOTS and SPIRES 
applications. Because the sharing of such resources means a 
substantial saving to all applications served, maximum attention 
will be given to the sharing concept. Wherever possible, 
advantage will be taken of the economies gained through providing 
major facilities for multiple applications. 

HARDWARE. The hardware environment will 
provide reliable, economical, and flexible 
support of applications. 

SOFTWARE . The software, consisting 
of an operating system, an on-line executive 
program, a terminal handler, a text editor, 
and other facilities, wi 1 1 be used 
jointly by various applications. 

The operating system will be supplied 
by the manufacturer of the hardware. 

GENERALITY/EXPANDABILITY. The shared 
facilities will be designed to allow new 
applications to be added without modifying 
previous ones. 
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2.0 PROTOTYPE DEVELOPMENT 



This chapter records the development and operation of 
the BALLOTS I prototype system. Since this report period also 
covers the first six months of activity in developing the BALLOTS 
II production system, some of the:; results of that effort will be 
included. This will show by contrast many of the lessons learned 
from the prototype experience. In various sections, the problems 
encountered in development will be frankly discussed, to make 
this report as valuable as possible to other 1 i bra r i es that may 
be considering large on-line system development. Not every 
project's problems will be the same but knowing the problems of 
previous efforts may prevent repeating them. Further problems of 
and requirements for on-line system development will be discussed 
in Chapter "3.0. 

2.1 Organization and Staff Fac.lities 

It was assumed at the outset of BALLOTS I that a large, 
computer-supported bibliographic control system could not be 
developed independently by the library. Expertise of a kind not 
normally found in the library would be required. The initial 
effort called for refining and extending the preliminary systems 
analysis of major technical processing functions that had been 
conducted as part of proposal preparation. To do this and begin 
the work of the project, the University's Systems Office assigned 
four full-time analysts to work under the supervision of a 
systems coordinator. Quarters for this staff were furnished in 
the library, close to the functions being analyzed. 

None of the newly assigned systems analysts had previous 
library experience and all demonstrated a now rapidly 
disappearing attitude toward library automat i on~~unde rest imat i on 
of task complexity. Immediately on beginning employment, all 
were given intensive bibliographic orientation and instruction by 
members of the library staff. 

The scheme of having an assigned task force belonging to 
an organization outside of the library was fine in theory, but , 
worked out poorly in practice. Members of the task force worked 
in the library and their work was performed on behalf of the 
library. Yet there was an uncomfortable ambiguity surrounding 
their reporting and supervision requirements. At times, it 
appeared to the library that the project and its staff "belonged" 
to the Systems Office, and that the matters in which the brary 
was interested were not receiving the full attention of the 
staff. Indeed, at one point, an assigned staff member was taken 
away from the project on short notice and assigned a different 
responsibility. Through negotiations, the library and the 
Systems Office succeeded in terminating this semi -contractural 
arrangement after some 15 months of less than completely 
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satisfactory "collaboration." The assigned staff from the 
University's Systems Office was formally incorporated into the 
structure of the University Libraries. The Automation Division 
(now Department) was established under the BALLOTS Principal 
Investigator, Allen B. Veaner, wl. . was a senior administrative 
officer of the library. A library analysis/design group manager 
reported directly to the department head. Later, Data 
Preparation and Data Control units (see subsections 2.10.2 
through 2.10.4) were established within the department as part of 
prototype operations. This resulted in improved supervision and 
communication, and increased the library’s commitment to 
automation. This organizational change also enabled the systems 
staff and the librarians to work together as professional 
colleagues, members of the same organization, rather than as 
outsiders to each other. 

Six months before the start of Project BALLOTS, 

Edwin B. Parker of Stanford's Department of Communication began 
Project SPIRES--the Stanford Physics Information REtrieval 
System-~a reference retrieval experiment aimed at servicing the 
need of high-energy physicists for rapid dissemination of 
preprints. Such dissemination is one of the key methods of these 
specialists for communicating the results of their experiments. 
Professor Parker had participated in the development of the 
BALLOTS Proposal and was already a member of the BALLOTS Faculty 
Advisory Committee. It: quickly became evident that BALLOTS and 
SPIRES had numerous common system requirements and goals and 
needed identical computer facilities for their research. in the 
Interest of securing the best return from their respective 
research grants, and wi th the full knowledge and cooperation of 
their respective funding agencies, the two principal 
investigators agreed to share and coordinate the intellectual 
resources and talents of the teams each had developed. An 
explicit: goal of this collaboration was the creation of common 
software useful for both library technical processing and 
information retrieval. The University endorsed this 
collaborative approach and established a joint SP I RES/BALLOTS 
Executive Committee to monitor progress and to be certain that 
each project was indeed fulfilling its responsibilities to its 1 
respective funding agency. Each project continued to maintain 
its separate identity with respect to fiscal accounting and 
reporting requirements,. The Executive Committee is composed of 
the Vice President for Research (now Provost), William F. Miller; 
the Director of Libraries, David C. Weber; the Director of the 
Stanford Computation Center, Charles Dickens (replacing Paul 
Armer); Professor Parker; and Mr. Veaner. 

Collaboration between BALLOTS and SPIRES in the research 
phase produced many benefits, but separate management and 
separate quarters made some aspects of coordination and 
communication unwieldy.. The analysis staff was in the Main 
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Library and the programming staff was in the Institute for 
Communication Research, two-thirds of a mile away, near the 
Campus Facility Computer. Often, daily contact between analysts 
and programmers is necessary. Documents and design plans need to 
be jointly discussed. In this situation a telephone is a poor 
means of communication. Following the decision to develop a 
production system for both BALLOTS and SPIRES, two significant . 
changes occurred: integration of the two separate staff units 
under a single director and physical unification of the combined 
staff under one roof. 

A. II. Epstein, formerly of the North American Rockwell 
Company and a key computing participant in that company's role in 
the APOLLO project, was appointed SPIRES/BALLOTS Project Director 
in the Stanford Computation Center in November 1963. At the same 
time,- Mr. Epstein was appointed to the Project Executive 
Committee. Mr. Epstein was given a joint appointment in the 
Computation Center and the University Libraries as a result of an 
internal reorganization in the University Libraries. Mr. 

Veaner, formerly Assistant Director for Automation and head of 
the Library's Automation Department, was appointed Assistant 
Director for Bibliographic Operations, with responsibility for 
Acquisition, Automation, and Cataloging. Mr. Epstein was 
appointed Head of the Library's Automation Department as well as 
Director of the SP i RES/ BALLOTS project in the Computation Center. 
These appointments strengthened the coordinated management of the 
joint CALLOTS/SP f RES project by ensuring that the Library's 
interests would be integrated into Stanford's long-range plans 
for computational facilities and services. 

The existence of development staff in two sepiirate 
locations had resulted in numerous difficulties in communicating 
and reaching a common understanding about various aspects of 
software design. Concurrently with the hiring of Mr. Epstein, 
the Executive Committee moved to collocate the entire staff. The 
Library supported the installation of a new temporary building, 
adjacent to the Computation Center, solely for the use of the 
SPIRES/ BALLOTS Project. This building was occupied in February 
1970. 



Staff turnover can be a serious problem. During 1968 
and 1969 the project lost two key analysts and three programmers, 
including the manager of the programming group. The scarcity of 
talent, plus high demand in the library automation and 
programming job market, make job shifts a constant threat to 
development schedules and substantive design work. Orienting, 
and in some cases training new staff members, slows down 
development by consuming experienced staff time, even after a 
concerted attempt has been made to recruit and retain competent 
technical staff. Plans must be made against the contingency that 
key people may be lost. Adequately documenting all system 



development activities seems to be the best way to reduce the 
impact of losing staff members. 

An i 1 1 ust rat i on of the project organization is shown 
as Figure 2 on the following page. 

2.2 Project Review and- Control 

2.2.1 Review 

Early in the project a Faculty Advisory Committee was 
established with the following members: 

Paul A rme r , then Director of the Stanford 
Computation Center; 

Richard Atkinson, Professor of Education and 
Professor of Psychology; 

Kenneth Creighton, Controller; 

Sidney Drell, Department Director and 

Professor, Stanford Linear Accelerator Center; 

Stanley Hanna, Professor of Physics; 

J. Myron .Jacobstein, Professor of Law and 
Librarian of the Stanford Law Library; 

Will i am R. Kincheloe, Senior Research 

Engineer, Stanford Electronic Laboratories; 

Joshua Lederberg, Professor of Genetics, 

Stanford Medical Center; 

William F. Miller, Professor and Vice President 
for Research; 

Edwin B. Parker, Associate Professor 
of Communication; 

Rutherford D. Rogers, then Director, Stanford 
University Libraries (now Director of the Yale 
University Library); 

Arthur Samuel, Senior Research 

Associate and Lecturer, Computer Science Department 

Wilbur Schramm, Director, Institute for 
Communication Research; 
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Claude M. Simpson,, Professor of English; 

Allen B. Veaner, Assistant Director for 

Automation, Stanford University Libraries; 

.David C. Weber, then Associate Director), 

Stanford University Libraries (now Director). 

The committee met quarterly to review progress, report the views 
df the faculty on library automation, and offer their assistance 
V'ith problems. Copies of the project's quarterly reports were 
furnished to the committee as a basis for discussion. The 
Faculty Advisory Committee was dissolved when the SP* RES/BALLOTS 
Executive Committee was established. 

The Executive Committee concerns itself chiefly with the 
examination and resolution of any internal matters that might 
hinder the two projects, such as the establishment of appropriate 
overhead rates for dedicated hardware, personnel evaluation, and 
the recruitment of managerial staff and systems programmers. The 
committee also reviews major reports and proposals prior to their 
submission to funding agencies.. The committee keeps the project 
informed about other related projects and interests on the campus 
that might have similar software and system requirements. 

Several have been identified, and the efficacy and practicality 
of the common software concept thus further strengthened. 

In the spring of 1968, an External Advisory Committee 
was formed to bring outside expertise into the project for 
purposes of review and evaluation. The members of the External 
Advisory Committee, all of whom serve without compensation, are: 

Mrs. Henriette D. Avram, Head, MARC Development 
Office, Library of Congress; 

Joseph Becker, President, Becker & Mayes, Inc; 

Donald V. Black, Systems Development Corporation; 

Richard DeGennaro, Director of Libraries, 

University of Pennsylvania; 

Samuel Lazerow, Chairman, National 

Libraries Automation Task Force, Library 
of Congress; 

Stephen A. McCarthy, Executive Director, 

Association of Research Libraries; 

Rutherford D. Rogers, Director, Yale University Library; 
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Charles H. Stevens, Associate Director 
for Library Development, Project INTREX. 

Two original appointees, Carl F.J. Overhage and Lawrence 
Buckland, were unable to continue serving on the committee and 
were replaced by Charles H. Stevens and Donald V. Black, 
respectively. James E. Skipper, formerly Executive Secretary of 
the Association of Research Libraries, filled in for the 
Association's Executive Director, Stephen A. McCarthy. The 
External Advisory Committee met in May 19C9 and in January 1970. 
Its comments and evaluations are sent directly to the Office of 
Education. 



An additional reviewing method consists of regular site 
visits by Robert L. Patrick, a computer specialist experience in 
on-line text-processing and bibliographic data applications. Mr. 
Patrick also contributes to major decisions on system design, 
hardware selection, and communication networks. 

2.2.2 Control 

A major purpose of a formal System Development Process 
(see subsection 2.5.2) is to break down the development effort 
into a series of manageable and interrelated tasks. Taken 
together, these tasks enumerate exhaustively the work required to 
produce a fully operational system. The tasks must be 
specifically and uniquely identified for assigning and 
scheduling. Breaking down the development effort into 
individually assignable tasks-Js the only way in which the 
management can control its resources- and guarantee that the 
development effort will terminate at a defin-Lte time, ~>roducing 
an operational system. " ^ 

Within each development phase, tasks are assigned and"--- 
coordinated by means of a Task Control Sheet (see Figure 3 on the 
following page). This form is prepared jointly by the person 
assigning the task and the person responsible for completing the 
task. it is initialed by both and contains a task completion 
date, a statement of the purpose of the task, a task description, 
and a statement of interfaces and constraints. All assigned 
tasks are recorded on weekly and monthly schedule forms (see 
Appendix G.7). These display all the tasks of a project staff 
member. When the task is finished to the satisfaction of the 
responsible person, it is stamped "COMPLETED" and is added to the 
project's formal documentation. It is also marked as completed 
on the schedule form of the responsible manager. Mo task is 
accepted as compl ete wi thout its accompanying documentation. 

After the task has been completed, hindsight comments 
are added, perhaps recording ways in which the task might have 
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TASK CONTROL SHEET | 

INITIALS: DATE: 4/.17 ] 



P E R S 0 N ( S ) A S S I c. N E D : Dou g Ferguson 

ASSIGNED R Y : : Hank Epstein 

USER: 



I NITI ALS:. 
INITIALS: 



DATE: ' l/l 7 | 

DATE: | 






A. 

5. 



6. 



TASK COMPLETION DATE 



4/23/70 



PURPOSE OF TASK: 



Forms, Standards B-l to B-15 
(DS.101 - DS. 115) 



nu,*vuvtr.» K«l Ml 



TASK DESCRIPTION: 

1) Finalize ins tructioiu, forms and samples for all Forms, 



2 ) 

3) 



Instructions on Standards pages with numbers assigned. 



Xerox adequate number of forms and establish Master Copy 
storage availability, and revision system. 



4) 

5) 



Xerox adequate copies for Project Control Notebook, 
Write Documentation Standard (DS .100) detailing 3 , 



I NTFRFAOFS/CONSTRA I NTS : 

Must be ready for Project Control Notebook distribution on 
4/24/70 



Final copy of forms and instructions to Documentation by 4/21/70 
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5 A// w — S'l/oojJ jfiip r©+yi(?p£. p s tS~t~ •yb&i r&jj * 1 



ERIC 



Figure 3 



2 3 



S B ~ l - C /t / 7 Q ) 



been performed more efficiently/ or citing problems that had not 
been anticipated. Material from this section is expected to 
provide valuable information for the future development of 
BALLOTS as well as for other library automation projects. 

A significant feature of the Task Control Sheet is that 
it must be approved by any user who is affected. For instance,, 
the Head of the Acquisition Department is asked to approve the 
outcome of every task relating to his area of responsibility. 

This gives users a practical orientation to the System 
Development Process, as well as ensuring that the user is 
intimately involved in the design of the system intended to serve 
him. The Documentation Standard (DS.002) describing the use of 
this form and a complete sample are in Appendix 5.7. 



2.3 Library Env i ronment 

The libraries of the Stanford campus consist of two 
groups. Most are part of the Stanford University Libraries 
headed by David C. Weber, who reports directly to the Provost of 
the University. In addition, there are six coordinate libraries 
(sucli as Law and Medicine), each of which is headed by a 
librarian who reports to the dean of the school or to the 
director of the supporting institution. These two groups are 
linked through the University Library Council chaired by Mr. 

Weber. Altogether there are over forty libraries on the campus 
and they employ over five hundred people. 

The Stanford University Libraries have a collection of 
1.8 millon volumes (the total for all libraries on the campus is 
about 3.5 million). The annual operating budget is approximately 
four millon dollars. The staff of the libraries includes 87 
professional librarians and 174 library assistants. Stanford 
University Libraries catalogs about 55,000 to 60,000 titles each 
year and acquires about 50,000 new titles every year. Figure 
4 illustrates the size and growth of the Stanford University Libraries. 
Forxfurther information on the organization of the libraries, size, 
and growth factors, see Appendix 6.1. BALLOTS is designed ' 

initially to serve the Stanford University Libraries. 

\ 

2.4 Computer Environment 

The S-fanford Computation Center consists of three major 
facilities: An IBM 350/50 at the Medical School, an IBM 360/91 at 
SLAC (the Stanfords L i nea r Accelerator Center), and an IBM 360/67 
at the Campus Facility. (The Controller’s Office operates an IBM 
360/40, designated tn£ s . Administrative Computing Facility. 
Organizationally, th i s N fac i 1 i ty is not a part of the Stanford 
Computation Center.) The^Qampus Facility's machine is the 
University's main computer 'for support of research and teaching 



TOTAL VOLUMES, MAIN LIBRARY SYSTEM 



GENERAL CIRCULATION 



thousands 

ol 

volumes 




thousands 

ol 

volumes 

500 — 



450 “ 



400 - 



’64 ’65 '66 ’67 '68 



EXPENDITURES FOR STAFF & 
ACQUISITIONS $3,962,431 

/ $ 



2,785,380 


70.3% 


Gtaff 


1,177,053”™ 


29.7% 




acquisitions 


1969-70 



Figure 4 

Growth of the Stanford University Libraries 



In the schools of Humanities and Sciences, Education, Earth 
Sciences, and Engineering. All three facilities serve 
approximately 5,000 users, and all offer terminal services. The 
Campus Facility is open 24 hours a day, seven days a week, and 
provides 136 hours per week of public services, the remaining 
time being set aside for hardware and software maintenance. Each 
major facility is headed by a Director, all of whom report to the 
director of the Stanford Computation Center. The project 
director of BALLOTS and SPIRES also reports to the director of 
the Stanford Computation Center. 

it is important for the reader to be aware that the Main 
Library and the Campus Facility are approximately a mile apart. 
This is a limiting factor on, for example, the rapid availability 
of highspeed printer output. 

2.4.1 Computer and peripheral equipment 

During BALLOTS I, Stanford's IBM 360/67 contained the 
following major components: 

1 CPU 

1,048,576 bytes of core 

2 7-track tape drives 

2 9-track tape drives 

4 2314 disc storage units 

3 2301 drum storage units 

3 1403 printers 

1 1443 printer 

2 2540 card read/punches 

2 2501 card readers 

1 2703 transmission control unit 

8 2260 display units 

(The IBM 2260's, used to display job status within the computer 
system, were removed from service in November 1970 and replaced 
with Hazel tine Model 2000 displays.) Approximately 200 IBM 2741 
typewriter terminals are available for public use at various 
locations around the campus; a number of these terminals are 
Installed at various schools and colleges in the Bay area in 
support of a regional network. Portable terminals are available 
for use with the networks maintained by common carriers. At any 
given time, eighty of the 200 IBM 2741 typewriter terminals can 
be using the 360/67 simultaneously. On the Stanford campus, 
almost all terminals are permanently connected to 360/67 the over 
voice-grade telephone lines. A number of terminals can be 
switched to use with the 360/50. Dialing facilities are 
available for communicating with other computers outside of 
Stanford. Portable terminals are also available for off-site 
demonstrations or for places where a fixed installation is 
inconvenient or impossible. Eight teletypewriters are also 
supported. The full equipment configuration is shovm in Appendix 
6 . 2 . 
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A steam-driven turbine provides a dependable 
electric power, independent of the hazardous line surges that 
characterize the electric power grid in this region, and of other 
dangers as well. The turbine was installed Following disastrous 
damage to the 360/67 on March 12, 1970, when an automobile rammed 
a utility pole feeding the substation that supplied electricity 
to the Computation Center. 

The initial proposal for Project BALLOTS envisaged use 
of the IBM 2321 Data Call for mass storage. This device, with a 
rated capacity of four hundred million characters, was attractive 
owing to its economy: twice the storage capacity of the 2314 disk 
for less than half its cost. The known penalty would have been 
in access time, which was expected to be four to five times the 
85-millisecond average access time on the 2314. A 2321 Data Cell 
was installed on the 350/6? on November 21, 19G8--but it was 
removed on December 1, 1968, owing to the manufacturer's 
inability to guarantee mechanical reliability and service depend- 
ability. The device was also under-utilized while it was 
available and hence could not be economically justified. (The 
2321 was removed before BALLOTS was able to make significant use 
of it.) However, there were two other reasons why the 2321 Data 
Ceil proved impractical: access to records stored on it proved to 
consume 360/67 overhead undul y--wh i ch all but destroyed its cost 
advantage over the 2314; and the time required for checkpointing 
its contents (periodic copying to back-up tapes) proved 
excess i ve--e i ght to ten hours to dump a full Data Cell onto tape. 
Since it is the Campus Facility's policy to checkpoint direct- 
access storage devices every two weeks, this is a real economic 
drawback. 

Rejection of the 2321 left only one available choice: 
the IBM 2314 disk, a storage device that has shown a high degree 
of reliability in the field. On the average, it takes less than an 
hour to dump a full 2314 disk onto tape. A 2314 for shared use by 
BALLOTS and SPIRES was installed on December 21, 1968, along with a 
dedicated selector channel to speed data transfer. Although it 
would have been possible to utilize an existing channel, channel 
equipment was already shared among three 2314's. An attempt to' 
attach one more 2314 would have resulted in queuing or 
contention, with consequent unacceptable delays in getting to 
records . 



n 

o 

ERIC 

ILL 



2.4.2 System software 
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The software environment as of June 1370 is illustrated 
in Figure 5 on the following page. Employing IBM's OS/MFT 
(multiprogramming wi th fixed number of tasks), the IBM 360/67 
offers batch processing, terminal text editing, remote job entry 
and retrieval, and time-sharing services. The OS nucleus is 



27 



35 



CAMPUS FACILITY 
STANFORD COMPUTATION CENTER 



SYSTEM 

OVERVIEW 



PARTITION SIZES IN 


BYTES 


03 NUCLEUS 


90112 


PRODUCTION BATCH 


3504 00 


Hl-SPEED BATCH 


] 351 63 


oi.v n. 


196608 


-'.Yl -BUR 


03960 


‘ILTI'.H 


53243 


HASP 


131072 




BATCH JOB SCHEDULING 
Hl-SPEED BATCH CONTROL 
SPOOLING 

REMOTE JOB ENTRY 
REMOTE JOB RETRIEVAL 
SYSTEMS- STATUS 0! Si* LAY 
BATCH ACCOUNTING 






Figure 5 

3 60/6 7 Sof twa re Conf i gu ra t i on 



28 



36 



I s 



ERIC 

hmtBiaff.Tiaaaa 
1 i 



stored in the OS partition. Other partitions illustrated in the 
figure are as follows: 

HASP (Houston Automatic Spooling Process). Controls 
peripheral input-output devices (readers, punches, 
printers); handles priority scheduling for two 
categories of batch work and performs batch accounting 
functions; maintains system status information (core 
utilization, number of jobs backlogged, etc.). 

MtLTi-N, Provides communication for term! nal -or iented 
systems, such as ORVYL, SP I RES /BALLOTS, and WYLBUR. 

It facilitates broadcasting by the operator and inter- 
terminal communication by system users. 

ORVYL. A time-sharing monitor that permits programs 
written by users to execute in a time-sharing mode. 

WYLBUR. A text-editing and remote job entry facility. 
(See subsection 2.10.2 below for further details on how 
WYLBUR is employed in support of BALLOTS). 

HI-SPEED BATCH. An extremely fast performing batch 
partition designed expressly to expedite the execution 
of short jobs submitted by students. Works independent- 
ly of the OS job scheduler. 

PRODUCTION BATCH. A large partition supporting all 
OS services; the workhorse for complex research computing 
tasks . 



The rates established for service on the 360/67 are 
based on a government-approved flexible pricing agreement, which 
has been documented by Nielsen <19>. Under this agreement, 
costing and pricing are separated, and an effort is made to 
spread the cost of various machine resources in a way that is 
beneficial to the users. Flexible pricing permits a fair and 
reasonable allocation of scarce or expensive resources that might 
otherwise be beyond the reach of system users. It permits the ■ 
income from popular facilities (such as terminals and remote job 
entry) to be applied to less used but still essential facilities. 
A significant feature of the government-approved flexible 
pricing arrangement is that the Campus Facility must charge all 
users the same rates for equivalent services. This policy had a 
major effect on the economics of implementing BALLOTS on 
Stanford's IBM 350/67 as configured in 1969-70, and will be dealt 
with separately in section 3.2, 



Appendix 6.2 contains a chart of rates 
1969-70 for all users of the Campus Facility. 



in effect during 
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2.5 Library Analysis and Design 

The libarary analysis group is responsible for analyzing 
the current procedures, deriving library operating requirements 
to be fulfilled by the computer system, and designing a manual 
system that effectively uses the computer system. 

2.5.1 BALLOTS I analysis and design 

Library analysis for BALLOTS i meant the study of manual 
files, documents (Input and output), and data elements, including 
descriptive (e«g., format) and quantitative information about 
each system element. This task was carried out by the library 
analysis group working with the library staff. From the 
information gathered., the analysis staff produced specifications 
on record content, indexes, data elements, and output formats. 

Defining the data elements was a basic system 
requirement. In order to define data elements, it was decided to 
follow the analytical approach suggested !*y Bregzis <6> rather 
than the traditional approach. In the analytical approach, the 
functional relationship of an access point to the total 
bibliographic record is given priority over the set conventions 
for naming data elements. All personal names associated with a 
given record are accorded equal weight in the analytical 
approach, whether they are main entries, joint authors, editors, 
etc., on the ground that the ultimate library user does not 
consider these niceties when he is searching for a particular 
work. Nor, without a good deal of training, does the 
non-professional searcher in a library technical processing 
depa r tment . 

Data elements were defined for three categories of 

da ta : 

control data 

full LC bibliographic data 
accounting data 

Each data element was defined by a standard name, a mnemonic (of 
one to three letters), a maximum and minimum length, and content 
editing where applicable. For each data element there were edit 
requirements in the data base build program, for whether it was 
singular or multiple, whether it was required in a record or not, 
and what its content specifications were (such as all numeric or 
all alphabetic). A personal name bibliographic main entry was 
tagged "A" for personal name. Its functional relationship to the 
work (main entry) was indicated by a separate data element "ME" 
that pointed to the main entry. Likewise, a second personal 
author was also tagged "A" and its functional relationship to the 
traditional structure of bibliographic records indicated by a 
supplementary element. Ninety-seven data elements were thus 



defined for the prototype system. The list: is included as 
Appendix 6.6. 
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The analysis staff's specifications were given to the 
programming staff, usually in the form of Library System Notes 
(see section 2.6). If explanations were needed, meetings were 
held between the staffs. The library's inexperience in writing 
on-line specifications was apparent; equally, the programming 
staff underestimated the complexity of library requirements. 
Communicating changes to specifications was not adequately 
con trolled. 



2.5.2 The system devel opir.jnt process 

A comprehensive system development process was employed 
at the beginning of the project and continues to be refined and 
extended. When the decision was made to develop a production 
system, the process was named the BALLOTS li System Development 
Process. A graphic representation of the elements of each part 
of the process is given in Figure 6 on the following page. 



The System Development Process has six overlapping 
phases, each with a specified documentary output. The six phases 
are : 



1. Preliminary Analysis 

2. Detailed Analysis 

3. General Design 

4. Detail ed Des i gn 

5. Implementation 

6. installation 



The Detailed Analysis Phase is described in some detail in 
subsection 2 . 5 3 because this is the most recent and significant 
RALLOTS li library activity. 
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Preliminary Analysis, based on experience with the 
BALLOTS I prototype, involved defining goals, describing the user 
environment, analyzing the existing system, selecting the system 
scope, and establishing the gross technical feasibility of the 
BALLOTS i implementation scope. This work is described in detail 
in a System .Scope document <25> that was the main documentation 
output of the Preliminary Analysis phase. 

Detailed Analysis enumerates system requirements 
minutely. Performance requirements are stated quantitatively, 
including response time, hours of on-line accessibility, 
allowable mean failure time, maximum allowable recovery time, and 
similar factors.’ Record input and output are determined in terms 
of volume, growth, and fluctuations. Timing considerations for 
batch input and output are determined, in order to plan for 
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scheduling requirements. All input and output record, screen, 
and document formats are determined character by character. 

Rules transforming input data elements into output data elements 
are formulated and tabulated. The upper bounds of developing and 
operating costs are established. 

General Design encompasses both system externals 
(procedures, training, reorganization, etc.) and system internals 
(alternative hardware and software solutions to the stated 
requirements). As a result an overall sof tv/are-hardv/are 
configuration is selected and outlined in a General Design 
document . 



Detailed Design completes the internal and external 
design, creates implementation and testing plans, and provides 
programming specifications. These factors are incorporated in a 
Detailed Design document. 



In the Implementation phase, user documentation is 
created and personnel are trained. Programs are coded and 
checked. Testing is done and the results are evaluated. 

Programs, maintenance documentation, and test reports are written 
up in this phase. 

In the Installation phase, files are converted, and 
following a period of parallel operations, during which the full 
system is evaluated and accepted by the library, a complete 
changeover is made to the new system. Performance statistics for 
the production environment are gathered over a ninety-day period. 

A support plan for continued operation of the system and a 
project history giving system details are completed. 

All the activities that occur during the system 
development process are scheduled and evaluated at key milestone 
po t n ts . 

2.5.3 BALLOTS II detailed analysis 

In the Detailed Analysis Phase, the precise, detailed ' 
requirements of an automated library bibliographic processing 
system are defined, analyzed and presented. These requirements cover 
every function the system is to perform-- they form a complete 
description of WHAT the system is to do. Basic to this task is a 
detailed system design/description that aids understanding and 
clarifies various analysis subtusks. The library is viewed 
extensively as a series of interrelated subsystems. In depth, it 
is viewed as a series of progressively more detailed levels of 
activity. To define precisely these levels of activity, a 
hierarchical model has been postulated: 



LEVEL 


EXAMPLE 




Subsystem 


Acqu i s i t i on 




- Process 


-Or dn i ng 




--Procedu re 


— Create new 


record 


---Ope ra t i on 


Key data 




-Step 


Key singl 


e data element 


Preliminary analysis description 


w a s p r i ma r i 1 y 


at the subsystem 



level. Detailed Analysis concentrates on processes, their 
component procedures and operations. For each subsystem process 
a book is prepared that contains data flow charts and analysis 
forms. The book as a whole presents a design scheme showing at 
what points (using CRT screens) records will be input, updated, 
and copied from file 'to file; at what points files will be 
searched; and at what points printed output will be generated. 

Detailed Analysis looks at the elements of the library 
system, determines which are important, and gathers information 
about them. in both its automated and its manual portions, the 
library is a file oriented processing system. Thus, information 
is needed about the description and contents of records and 
files. Data elements in these records also must be identified 
and described unambiguously. Each process of a system produces 
several outputs (usually but not always printed) from several 
inputs. The data elements in the input are transformed in the 
course of processing; their transforms must appear correctly on 
the required outputs. Hence, inputs must he described, printed 
outputs formatted, and processing rules stated unambiguously, A 
system employing video displays, such as BALLOTS II, has par- 
ticularly stringent requirements for accurately describing and 
specifying the format, content, arid processing rules for the 
display screens. System interfaces must be described and system 
controls stated. Performance requirements of cost, timing, and 
schedules are established, and any organizational requirements 
(such as a new organizational unit, like Data Control) and 
training requirements (such as a terminal operator training 
program) are described. In addition, any computer system rests 
upon certain assumptions and concepts that require management 
decisions. To promote clarity and completeness, these are 
developed and put in writing for discussion and approval. 

Appendix 6.4 contains a list of representative assumptions and 
concepts, along with the management decisions that were presented 
to the library administration for discussion, modification, and, 
f i nal 1 y, approval . 

The information gathered is needed in precise-- 
preferably in quant i tative — detai 1 , Size,, volume of activity, 
and frequency of occurrence are typical of the required measure. 
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Performance requirements are stated quantitatively, including 
such factors as response time, hours per day of on-line service, 
and allowable mean time between failures. Record input and 
output are estimated in terms of volume, growth, and 
■ fluctuations. All input-output documents are laid out in 

character-by-character detail. Transformation rules between 
) input and output data elements are specified and cost limits 

! establ i shed , 

, - In presenting the needed information, the volume and 

\ complexity of bibliographic processes virtually rules out use of 

a narrative format, '/ell-designed forms are the most convenient 
medium for recording and displaying the quantitative and 
j qualitative data necessary to establish system requirements. 

( • About twenty forms forms have been designed and tested for 

BALLOTS II. A draft copy of each form was developed and 
criticized. A standard was next written giving instructions for 
j filling out the form. This ensured uniformity in data collection 

and presentation. After several critiques, representative and 
comprehensive examples of completely filled out forms were 
i prepared. This effort resulted in thoroughly pretested and 

documented forms known to be satisfactory to the analysts arid 
, librarians. A complete set of analysis forms and their 

' associated documentation standards is given in Appendix 6.3. 

( 

Thus, the Detailed Analysis Phase enumerates the 
I complete functional requirements of the production system. The 

( : results of the Detailed Analysis Phase are to be presented in a 

requirements document. An example of a requirements document is 
<i the document for the Acquisition Subsystem, which totals over 600 

!; pages. !t is estimated that the combined set of subsystem 

requirements documents that will make up the BALLOTS II 
Requirements Document will total approximately 2,000 pages. 

2.6 Internal Project Documentation 

[I In BALLOTS I, library specifications were presented in a 

i' series of Library System Notes. Technical specifications were 

presented in a series of Computer System Motes. Examples of both 
i types of notes are in Appendix 6.6. Library analysis data was 

1 prepared on forms and collected into notebooks. Requirements for 

library processing (e.g,, use of MARC tapes) were prepared as 
Library System Motes and forwarded to the programming group, 
i Design specifications implementing these requirements were 

prepared as Computer System Motes and reviewed in turn by the 
library analysts. Interpretations or elaborations of documents 
1; prepared by one group required making extended telephone calls or 

I. i holding meetings at the library or the Campus Facility. There 

was no formal change control procedure for documents, and this 
j resulted in documentation that was incomplete and inconsistent 

i with the design. Although this documentation was suitable for 
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prototype development,, developing a production system requires 
more complete, detailed, and controlled documentation. 

An on-line bibliographic control system for a large 
library is incredibly detailed. For example, the requirements 
document for the Ordering Process in the Acquisition Subsystem 
totals 300 pages, and over 600 pages are needed to specify the 
system requirements for the entire Acquisition Subsystem. 
Preparing, organizing, and updating large amounts of complex 
documentation requires the highest degree of standardization 
and discipline. A recent major work on data processing 
management <23, p. 11> states that 

» 

<The system development proces ? s> puts documentation 
where it belongs: equal in importance to analysis, 

design, and programming. More management effort 
often must be exerted to obtain good documentation 
than is required to obtain good analysis, design, 
or programming because analysts and programmers, 
upon completion of those segments, feel that they 
have completed their assignments. Unless docu- 
mentation standards are both clearly designed and 
rigorously enforced, however, the resulting 
documentation will be both garbled and inconsistent 
In quality. 

Two major tools for managing project documentation have been the 
development of standardized analysis and design forms and the use 
of computerized text editing, to maintain and update both forms 
and narrative material. indeed, without the ready availability 
of the text-editing system, it is doubtful that a project of this 
•magnitude could maintain consistent internal documentation. 

A Project Control Notebook is maintained, in which all 
project documentation standards are enumerated and defined, and 
all forms explained, with examples. A copy is issued to every 
staff member and to librarians who are participating in system , 
development or are expected to be major system users. Figure 7 
is a partial listing of the contents of the Project Control 
Notebook . 



Documentation is controlled by the Project Editor, who 
is assisted by a support staff responsible for producing finished 
documents from material prepared by the project staff, as well as 
distributing and maintaining them. In general, a task is not 
considered complete until it has been documented (see section 
2.2). This fact has proven exceptionally effective in assuring 
rapid delivery of documentation materials. 

Each type of system component in the BALLOTS II system-- 
procedure, file, record, screen, hardcopy input or output-- is 
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Identified within a unique mnemonic-numbering format, prefixed 
by a system or subsystem mnemonic. Each subsystem is assigned 
a two-character mnemonic, such as CT for Cataloging and AQ for 
Acquisition. Each process within a subsystem is assigned a 
three-character mnemonic. Each procedure within a process is 
serially numbered. in the Ordering Process of the Acquisition 
Subsystem, there is a procedure in which a librarian keys a 
search request for the MARC file. This is a manua 1 -automated 
procedure followed by an automated procedure in which the MARC 
file is searched and various output screens displayed. Following 
are this and some other system elements with their 
identification codes. 



SYSTEM ELEMENT 



ID# 



Acquisition SUBSYSTEM 
Ordering PROCESS 
Key MARC search PROCEDURE 
Search MARC file PROCEDURE 
MARC FiLE 

Search inquiry screen (INPUT) 
Search result screen (OUTPUT) 



AQ 

AQ. ORD 
AQ.0RD.13 ' 
AQ. ORD . 18 
BMRC- 

AQ . ORD . S I 0 1 
AQ. ORD. SRO). 



The proper identification code appears on each form 
describing a system component, and throughout the project 
documentation that system component is referred to by its 
identification code. The code structure shows what procedures 
are part of the same process and what screens are part of the 
same process. The file code shows, for example, that the MARC 
file (MRC) is available at various points throughout the BALLOTS 
li (3) system. The naming/number i ng conventions For constructing 
identification codes are given in Appendix 6.4. A listing of all 
subsystems, processes, and files, with their associated codes, is 
given in Appendix 6.4 also. 



The flow of data through bibliographic processing is 
presented in the form of system flow charts. These charts, along 
with the naming/numbering conventions, are intended to ensure 
communication between 1 i bra r i an-users and the library analysis 
group, and between library analysts and the programming group. 
Between users and analysts, they are intended to maximize 
understanding and they also form the basis of management's 
approval of the proposed system flow. Between analysts and 
programmers, they form part of the documentation necessary for 
writing program specifications. A common understanding of system 
charts is achieved by defining a set of symbols and their 
interpretations, and specifying conventions in the use of, for 
example, flow lines and comments. Appendix 6.4 contains the 
detailed standard employed for BALLOTS II flowcharts. 



2.7 



Software Design and Development 



BALLOTS I software design and development was carried 
out by the combined BALLOTS/SPIRES programming staff at the 
Institute for Communication Research. Specifications were 
provided by the library analysis group. The overall system 
design called for creation of an on-line In Process File. 

Records of bibliographic data (including all -information 
necessary for acquisition and cataloging) were to be created and 
updated from input entered at terminals in the library and files 
were to be searchable on-line. Data copied from MARC tapes was 
to be y used in creating the record whenever possible. Purchase 
orders, claims, cancellations, and catalog cards are the needed 
outputs. To support this a structure was created which included 
an on-line executive, search and retrieval programs, a file 
building programs, and programs for printed outputs. 

2.7.1 On-line executive program 



The prototype system supervisor is an on-line executive 
program designed and developed by project personnel to service 
several on-line users simultaneously. The purpose of an on-line 
executive program is to regulate competition for service and 
resources among several terminal users. The program attempts to 
ensure that each user gets a reasonable share of available 
execution time. Experience with the the prototype supervisor has 
demonstrated the feasibility of the approach taken; response time 
averages three seconds for simple search requests. The 
scheduling algorithm in the time-sharing monitor allocates CPU 
cycles according to the priority of each partition. (See 
subsection 2.4.2 for review.) SPIRES/BALLOTS I performed in the 
production batch partition. Hence, a request for service by any 
other partition except High-Speed Batch automatically pre-empted 
CPU cycles. On days when activity was high, the response time 
for SPIRES/BALLOTS was degraded, an inevitable result in this 
particular computing environment. 

Details of the on-line executive program are contained 
in the BALLOTS Quarterly Report for the period ending June 25, 
1969 <2> . 

2.7.2 Internal file structure 

The internal file structure minimizes the need for 
extensive reorganization of the file when new materials are 
added. New references are added to the data base in whatever 
order they are received. A major objective of the file structure 
design is to avoid serial searches; such searches are tolerable 
on very small collections, but cannot be made efficient for files 
of the size contemplated by BALLOTS, instead, access to the 
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appropriate references is achieved through a series of inverted 
index files. Each indexing term in the files is. followed by a 
list of pointers indicating the locations of the references in 
the data base that contain that indexing term. In the prototype 
system the following indexes were defined: 

Author 

Title word ( s ) 

Corporate author 
Conference author 
Identification number 
Topic 

The Topic index was not implemented in BALLOTS I because subject 
access to the library's In Process File was not required by the 
library staff during prototype operations. (However, subject 
access was provided for ERIC flies and for the file of African 
History references.) The date of each document is stored with 
each address pointer in each index. This makes it possible to 
restrict searches to specific dates without having to use the 
master file of bibliographic records and without having to 
establish a separate date index, which could produce unmanageably 
large stacks of pointers. 

2.7.3 Data base format 

One or more logical records (bibliographic entries) are 
stored within a physical record or "block." For the prototype 
system this block length was set at 3,520 bytes (eight-bit 
characters). The organization of a data base block is shown in 
Figure 8. The first two bytes contain the block number, the 
second two bytes contain the number of entries in the block, and 
the third two bytes contain the location of unused space within 
the block. The last four bytes in the block are a trailer 
containing an address pointing to the actual location of the 
first logical record within the block. This trailer is the 
address pointed to by the index files. Should it prove necessary 
to expand the logical record so that it no longer fits within the 
space originally assigned, then it can be located in some other 
space (not necessarily in the same block) and the trailer changed 
to indicate that location. No modification of the existing index 
files would be required when such a change is made (unless index 
terms were deleted). 

There are several possible ways in which the logical 
record itself might have been organized. Potentially, a large 
number of data elements might be associated with each 
bibliographic record. Inasmuch as over four hundred data 
ejlements have identified by Curran and Avram <10>, it would be a 
very inefficient use of space to assign a fixed-length record 
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BYTE LOCATION 



BLOCK CONTENTS 
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Figure 8 

Data Base File Format 
4 I 




format for each possible data element/ or even to assign a fixed- 
length heading for each possible data element with a variable- 
length record only for those actually present. One feasible 
alternative is to have a va r i abl e- 1 ength-head i ng field consisting 
of pairs of labels and pointers. The retrieval of any particular 
data element (e.g. author) would begin by searching the first 
half of each pair until the "author" label was found/ and then 
proceeding to the location specified by the associated pointer to 
find the variable-length author field. Another/ the alternative 
chosen for this project/ was to have a system data element 
descriptor table in which each possible data element is numbered 
in approximately descending order of frequency of occurrence. 

This data element number can then correspond to the position in a 
"bit mask" or "bit table" at the head of each logical record. 

For example, when data element number 16 is present, the 16th bit 
(«.e., the last bit in the second byte) can be set to 1. When it 
is absent, that bit can be set to 0. Thus a "f i xed- 1 ength 
heading" for 32 possible data elements can be stored in one 
four-byte word. When all the remaining bits in a bit heading are 
zero, then the bit heading itself can be truncated to the nearest 
byte. For each data element actually present in the given 
logical record, a fixed-length heading indicates the starting 
location of that data element, the length of that element, the 
number of values present (e.g., the number of authors) and the 
number of "sets" into which those values are grouped. One 
example of the flexibility this last feature permits is the 
grouping together of authors from the same institution into the 
same "set," in such a way that there is a one-to-one 
cor respondence between sets of authors and sets of institutions. 
This file organization requires a mixture of al phanumer i c- i ntege r 
and b i t-s tr i ng values within a variable-length record. 

The first two bytes in the logical record indicate the 
total number of bytes in the entry. The next two bytes indicate 
the number of data elements present for that entry (the number of 
l's in the bit mask) and the length (in bytes) of the bit mask. 
The bit mask itself follows. After the bit mask there is a 
series of six-byte headings, one for each data element present. 
(The third heading would be for the third data element present, ■ 
l.e., whatever element is associated with the third 1 in the byte 
mask.) The first two bytes of the six indicate the location of 
the value, the second two bytes indicate the length, the fifth 
byte indicates the number of values in the element and the sixth 
Indicates the number of sets. Within each variable length, the 
first byte indicates the set number for the first value (e.g., 
the first author), and the next two bytes indicate the length of 
that value. Each succeeding value is preceded similarly by three 
bytes of descriptive information. 
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2.7.4 Index file organization 



In the prototype system, data base files (themselves 
created by the computer programs that read in the "input format" 
discussed above) are read into the index building programs to 
create the index files. The logical plan of the structure for 
each index is that about half the available space will be divided 
into physical blocks (for example, perhaps 300 blocks). A "hash 
coding" calculation, treating the bits of the index term as if 
they were integer numbers, is used to select one of the possible 
blocks for each index term. A similar calculation on retrieval 
will permit the search to be immediately narrowed to the 
appropriate section of the index. The remainder of the indexing 
space will be used for overflow blocks, linked to whichever of 
the basic index blocks have been filled up. This scheme permits 
efficient retrieval without linear searches of a large index 
file, and without requiring reorganization of the index file 
whenever new entries are added. There is no commitment to stay 
with hash coding as the primary index access procedure. A 
balanced tree structure might well be more efficient. The hash 
coding scheme was easy to implement as a first version and 
permits the collection of statistics necessary to create balanced 
tree structures. 




Within each block in each index file there are two 
index terms (such as an author's name) and secondary entries (for 
all following occurrences of references with the same index 
term). Trailers at the end of the physical blocks point to each 
initial entry. Secondary entries are chained together and to the 
corresponding primary entry by a series of pointers. r ^ure 9 
shows the organization of one block in the index file. The first 
two bytes contain the block number, the next two conf- n the 
number of initial entries in that block, the fifth and sixth 
bytes indicate the location of unused space within the block, and 
the seventh and eighth bytes indicate the address of the 
following overflow block. Two-byte pointers to the address of 
initial entries within the block are in the trailers at the end 
of the block. Each primary and secondary entry has first the 
four-byte pointer to the corresponding data base entry from which 
that index term was taken. The next four bytes contain the 
address of the next secondary entry. This is set to zero if 
there are no additional secondary entries. Two bytes are 
reserved for the date of the reference being indexed, one byte 
for the type of entry (e.g., monograph, journal preprint, 
conference paper, and so forth), one byte for the source (i.e., 
MARC or other data tape service), and one byte Is reserved for 
special use in each index. Each primary entry has in addition a 
byte indicating the length of the va r i abl e- 1 ength indexing term 
or key plus that index key itself. 
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BYTE LOCATION 



BLOCK CONTENTS 



OOOl 

0003 

0005 

0007 

0009 

0011 

0013 

0015 

0017 

0019 

0021 

0023 



2196 

2198 






Block Number 


1st 

bit* 


Number of initial entries 




Location of unused space 




Overflow block pointer 




Data base olock pointer 




Data base address pointer 


Secondary entry block pointer 


Secondary entry 


address pointer 




Date 




Special 


Document • 
Type 




Source 


Length of 
Key 



KEY 




ENTRY 1 




ENTRY 2 




TRAILERS 



*If the 1st bit of byte 0003 is "on" (1, not 0), then there is an 
available space chain in th^ block. 



Figure 9 

I ndex File Forma t 
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This index structure has proven workable in the 
prototype system but it can be Improved upon. Substantial 
modifications are planned for SALLOTS II. 

2.8 TERMINAL SELECTION 

As documented in the MARC Final Report <1>, the 
conclusions of the RECON Working Task Force <7>, and the work of 
the University of California Institute of Library Research <7>, 
the input problem is universally recognized as the key issue in 
building the files required for automated bibliographic control. 
Hence, a prime concern at the beginning of BALLOTS was to 
determine the method of keying bibliographic records. 

The use of paper-tape devices was rejected at the outset 
for several reasons: the evidence of poor reliability from the 

MARC l experience; the difficulty of handling, identifying, and 
storing segments of tape; the difficulty of making corrections; 
and the lack of paper-tape-handling equipment in the Computation 
Center. (It should be noted that not all library experience with 
paper-tape typewriters has been negative <14>.) Even if the 
center had had such equipment, it is doubtful that tape would 
have been employed, because of the first three reasons. 

In preparing data for the computer-produced book catalog 
of the J. Henry Meyer Undergraduate Library, Stanford had amassed 
considerable experience in using punched cards for entering 
bibliographic data. This experience, which has been documented 
by Johnson <13>, established the feasibility of handling 
diacritical marks, capitalization, and special characters by 
means of key punching--at least for a collection limited to 
undergraduate materials, and characterized by a rapid decline in 
new input once the initial collection was established. But it 
seemed that the keypunch method should not be extended to 
comprehend special characters beyond the 100 graphics defined for 
the Meyer catalog, nor should it be used for the sizable input 
and update requirements of a large research library. Keypunching 
would have been especially unsuited to the rapid update 
requirements of on-line systems. 

The on-line typewriter terminal was chosen as the input 
device for several reasons: ready availability; existence of 

ready-made software (WYLBUR) for text editing; and the desire to 
employ terminals expressly designed for use with an on-line 
computer system. Since terminals were already required to reach 
and search on-line files, they could be used for input with no 
added hardware costs. 

Following are the features of the IBM 2741 terminals for 
use on Stanford's IBM 380/67 <38>: 
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REQUIRED: EBCD keyboard 

Dial-up facility option 

Dual data 1, t ie ball 963 print element 

OPTIONAL: Interrupt 

Typ-a-matic 
Reverse break 

The reverse break feature is a standard Item present on all 
Stanford terminals. It enables any on-line terminal to 
communicate with any other active terminal. The graphic 
character set available on the IBM 2741 Model 1 with type 
ball 963 contains: 



j LOWER CASE 

abcdefgh i j klmnopqrs tuvwxyz 
0123456789 
-60$#,./ 

j UPPER CASE 

ABCDEFGH I JKLMNOPQRSTUVWXYZ 
.• )*<;:%’>*( 

M _+$!"r? 

Note that a significant number of these graphics had been 
j selected for computer programming applications. Included in 

!- these were: 



i i 
v r 



0 

0 

G 



o 



ERIC 

kAL’LTlmlTLJ 

u 



<>*#r 

It would have been possible to design special en r jding routines 
and to write the programs required to omh' .< special graphic 
characters within tie conventional 2741 character set. However, 
this would have required an additional programming effort clearly 
outside the scope of a BALLOTS prototype implementation. 

Examination and use extablished the utility of WYLBL'R 
(the text-editing and remote job entry software) for entering 
bibliographic data. This eliminated the need to write special 
terminal monitoring facilities and text editors, and freed 
project programmers to work on developing the on-line search • 
facility. Using VJYLBUR eliminated the need for terminal users in 
the Stanford environment to learn two different command languages 
or become accustomed to two different terminals. it also did 
away with the need for additional core and CPU (central 
processing unit) resources to support a different text editor. 

Some disadvantages accompanied the decision to use the 
IBM 2741 typewriter terminals and VIYLBUR. The IBM 2741 is 
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delivered In three different code configurations.. To establish a 
campus s tanda rd--cons i de red essential if consistent, dependable 
service was to be of f e red--the Computation Center chose a 
terminal that emits EBCDIC code. This choice, made prior to the 
establishment of BALLOTS and without bibliographic applications 
In mind, .was considered a given in project development. 
Accordingly, it was decided that BALLOTS would not attempt to 
solve the problem of graphic character representation, especially 
since it was already being worked on by the Information Systems 
Office at the Library of Congress. The difficulty of this 
problem has been well described by Cunningham et al . <9>. 

The ready availability of video terminals as standard 
hardware* in third generation computing equipment offered the 
attractive possibility of doing away with the noise and slow 
response time of typewriter terminals. The Stanford Computation 
Center agreed to provide software support for IBM Model 2260 
video terminals to be installed in the library, but the IBM 2260 
equipment presented problems almost at once, well before the 
proposed installation date, and the order was cancelled. 

IBM 2260 terminals had already been installed at the 
Computation Center for monitoring and displaying system status to 
staff and users. The Computation Center's evaluation of the 
device indicated i cs suitability for passive display and its 
relative unsuitability for negotiating searches or for text 
editing. (All IBM 2260's have since been removed from the 
Stanford Computation Center and replaced with 'Hazeltine Model 
2000 units. The new units also are used only for passive display 
of system status to users and computer operators.) To satisfy 
the interest of Project BALLOTS in the 2260, a number of units 
were placed into normal service and made available for trials 
using WYLBUR and the on-line search facility. In each instance, 
it was quickly apparent: that the IBM 2260 would not be a 
satisfactory communication instrument for bibliographic 
retrieval . 



The 2260 is designed to function more like a fast 
typewriter than a flexible visual terminal. Like the typewriter 
terminal, it functions on a "1 ine-at-a-time" basis, and is much 
more suitable for fixed format, fixed length data. To summarize 
the limitations of the IBM 2260: 



1. The character repertoire is ve’ry limited and 
consists of upper case characters only. 

2« Characters, formed by a 5 x 7 dot matrix, are 
of poor qual i ty . 

3, The writing speed is fairly slow. If messages 
must be written to many screens at the same time. 
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It might take as much as four seconds to fill an 
entire screen. Further, the addition of new data 
to any part of the screen requires rewriting the 
entire sc reen . 

4. The Display Control Unit (IBM 2848) operates as a 
commutator that services only one keystroke request 
at a time. When any one key is being serviced, 
other terminal keyboards are locked out and the 
typist's rhythm broken up. 

5. Several units examined exhibited line distortion 
at the edges of the screen, an indication of 
maintenance or design inadequacy, 

6. Units lacked the "typ-a-mat Ic" feature. Continuous 
operation of the space bar or back space was not 
poss i bl e . 

7. Two keystrokes are required for data transmission. 

8. Cursor controls are slow and difficult to use. 

9. Preformatted fields, such as data element tags, 
cannot be protected from user alteration. 

Bibliographic messages vary widely in total length and 
in the length of each field. An effective bibliographic display 
system must be able to accommodate these variations and must 
offer the ability to display a large number of characters at a 
high writing speed. Part of the reason for the low data rate of 
•the 2260 is the limitation imposed by the 2400-baud telephone 
line that links the computer to remote locations. With 
asynchronous transmission, a 2400-baud line limits the character 
transmission rate to a maximum of 240 E3CDIC characters per 
second--or four seconds to write a 960 character screen. A brief 
response message can be anticipated only when the searcher is 
seeking an exact match, i.e., when he already knows in advance 
exactly what he is looking for. In an acquisition system this is 
likely to occur during a receiving operation (when the book is in 
hand) but not during an initial search when the only information 
in hand is a book requisition. Thus, the searcher must be 
provided with substantial "playback" ability — he must be able to 
scan a large amount of data on the screen, possibly even looking 
at several records at once. It was felt in BALLOTS I that the 
user should be able to view a graded series of outputs, ranging 
from brief to full records, and that the minimum display 
capability should be 1,000 characters, although 2,000 to 3,000 
characters were preferable. 
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The only way to achieve a data rate higher than that 
provided by a telephone line Is to Install a wlde-band, high- 
speed data link/ along wi th terminal equipment matched to the 
transmission facility. Two high-speed terminal systems were 
found that met the requirements for rapid display: the Data Disc 
Television Display System and the Computer Communications CC-30.. 

Following is a tabulation of the major features of each 

display: 



Featu re 

Character set 
Dot matrix 
Characters per line 
Number of lines per screen 
Total number of display positions 
Incremental cost of adding one 
display to system 
Time to write a full screen with 
all di spl ays act i ve 
Minimum cost to support a single 
display/ not including computer 
i n terf ace 



Data Disc 


CC-30 


ANS 1 


ANSI 


7 x 10 


5x7 


64 


40 


40 


20 


2560 


800 


$1,000 


$7,800 


1 second 


1 second 


$38,000 


$7,800 



The Data Disc system was clearly advantageous for five or more 
terminals, since the cost of adding CC-30's was completely 
linear. The 7 x 10 dot matrix of the Data Disc was clearly 
superior to the 5x7 dot matrix of the CC-30 for lower case 
characters. An attractive feature of both systems was the ANSI 
set of 128 characters, Which permits the display of all 
lower-case and many special characters. Equipment with ANSI code 
would have enabled BALLOTS to conform to the newly issued Federal 
Standard Code for Information Interchange (equivalent to ANSI 
code X3. 4-1968), the same code in which MARC data were encoded 
and distributed. However, since the IBM 360/67 operates not on 
this code but on IBM's own EBCDIC code, little actual advantage 
would have accrued. 

Unfortunately, the Data Disc system failed to perform 
properly in several demonstrations, and the manufacturer finally 
conceded that all data would have to be stored with 100 percent 
redundancy to guarantee performance. This Immediately cut in 
half the disk storage capacity and correspondingly reduced the 
number of terminals that could be supported simultaneously. The 
manufacturer was also uncertain as tc whether or not his devices 
could operate remotely at the distances between the Computation 
Center and the Library, approximately two-thirds of a mile 
including twists and turns. The high cost of adding one more 
terminal and the limited number of displayable characters ruled 
out the CC-30, and both devices were dropped. 
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For some time, the Campus Facility wanted to be able to 
view a "snapshot" of a full page of printed output, which is 132 
characters wide and 60 lines long. This desire, coupled with 
requests from BALLOTS and many other users for graphic display 
capability, led the staff of the Campus Facility to investigate 
visual displays that would be inexpensive to purchase and would, 
consume less core than the usual refreshed display does. With 
its own resources the Campus Facility installed a standard 
Tektronix 611 storage tube device, the same device that had been 
used in Project INTREX for passive, display of remotely 
transmitted microstore images. A demonstration was conducted for 
BALLOTS, and the advantages and disadvantages were considered. 

The storage tube is basically an inexpensive means of displaying 
data that does not change very much or very rapidly for a 
reasonable length of time — up to 15 minutes. The image is 
written rapidly, is of high resolution, and is quite bright at 
first, then facies. The period of real image brightness is very 
short--less than a second. The residual image is optimally 
readable under shaded, protected conditions. Such conditions are 
not likely to be found in a modern library. Furthermore, using 
any passive storage display with a typewriter terminal for input 
involves two other disadvantages, the noise of the typewriter and 
the relatively slow response, owing to the complex electronic 
circuitry and the time delays in CPU data processing. The 
typewriter terminal does produce a hard copy of the search that 
could be used for operator training and evaluation. But the 
disadvantages of the terminal taken with those of the Tektronix 
611 were too many, and the combination was judged unsuitable for 
BALLOTS. 



Finally, the inability to use video terminals in 
BALLOTS I was related to the kind of service provided on 
Stanford's IBM 360/67. Most of the users are students and 
researchers performing interactive work at terminals. in support 
of their jobs, some 60,000 different data sets and programs are 
maintained on disk files., Each data set is brought into and out 
of core storage whenever it is being used, and computational 
results communicated back to the user through the terminal 
handler (MILTEN). A similar interaction takes place through 
WYLBUR, the text editor, whenever n ew programs and data sets are 
created. This means that any very active terminal system is 
handling intensive communication activity. Such activity has a 
direct bearing on the feasibility of using video terminals, 
because video terminals require bulk data transfer; i.e., the 
transmission of several thousand characters within a fraction of 
a second. In this respect, one video terminal is the equivalent 
of a number of slow-speed typewriter terminals. The required 
transmission rate is not a problem — this is easily handled by a 
coaxial cable — but the message-switching capacity might be 
overtaxed, and the "store and forward" capability of the Campus 
Facility's terminal communication system impaired. A limited 
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number of remote terminal buffers and remote terminal control 
blocks (which take precious core) now service up to about eighty 
2741 . "1 i ne-a t-t i me" terminals simultaneously. bach slow-speed 
terminal can accumulate up to 132 characters/ and a "probability 
game" is played as to the length of time any user's line will be 
resident in the buffer before it is written onto disk or 
transferred elsewhere for processing. If all the buffers are 
full, the user is informed that his request for service has been 
queued. Several video terminals pre-empting valuable buffer 
space would significantly reduce the number of users able to use 
the fac i 1 i ty . 

As a footnote to this discussion of video terminals, it 
may be noted that many other devices were looked at, including 
the following: Philco D-21, Bunker-Ramo 2204, Stromberg 
Datagraphics SD 1110, Uniscope 300, Burroughs BIDS, Sanders 720, 
Raytheon DIDS-400, General lilectric's Datanet-76 0, RCA 70/756-51/ 
and Control Data 210. A number of these devices existed only as 
specifications at the time of inquiry. Some would have required 
extensive hardware and software preparations to interface with 
the 360/67. When terminals come along that are both better and 
cheaper, they will be obta i ned--but only if it can be proved 
beyond a doubt that they will function wall in a production 
environment. Peripheral equ i pment--pa rt i cu 1 ar 1 y if not made by 
the manufacturer of the main f rame--cannot be purchased on the 
basis of promises and specifications. 

2.9 On-line Interactive Searching 

The on-line search facility described below was used by 
librarians and technical processing assistants. 

2.9.1 Program residence 

The BALLOTS on-line search facility resided in a 
358,000-byte partition of high-speed core on the IBM 360/67. 

Since this arrangement pre-empted the Campus Facility's 
production batch, various attempts were made to work out 
alternatives. These included: (1) program overlays to reduce 
partition size, (2) installation of IBM bulk core, and (3) 
utilization of non-IBM high-speed core. The first alternative 
was rejected on the ground that response time would be 
unfavorably affected. The second alternative proved impractical 
since Stanford's IBM 360/67 was an early model without a 
connection facility for bulk core. The third alternative was 
very actively explored, but the vendor was not sufficiently 
confident in his product to guarantee performance, and all 
negotiations were dropped. 
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2.9.2 Search language 

The search language, as Implemented In the prototype 
system, is of the form 

find title classical studies and not title 

greek and (author john smith or author 

william jones) and date between June 1960 & 1963. 

Subsequent statements may be added to narrow the search results 
to a smaller list of references meeting both the earlier and the 
later specifications; i.e., the new list is logically "and-ed" 
with the previous list. This implicit "and" can be overridden 
with an explicit logical "or" symbol ( | ) as the first symbol in a 
following statement, if the user wishes to expand rather than 
narrow the search. 

When the resulting list of citations is sufficiently 
small that the inquirer wants to browse through the references 
found, then he can issue the command, "list" or "print." This 
displays on the typewriter terminal information about each 
reference in the sequence found. 

The date search comes in three forms: "date between," 
"date before," and "date after." The date may be specified in 
any of the many forms in which the date can be cited in English 
(except roman numerals), with the one exception that if the date 
is specified as three numbers then the order is presumed to be, 
month, day, year. (If a user mistakenly uses the European or 
military order of day, month, year, then confusion might arise.) 

| 

Authors' names may also be presented in almost any form. 
If they are presented surname first, a comma 

must separate the surname from the given names or jinitials. If 
the names are presented in the usual surname-last ‘position, then 
the program presumes that the surname is that character string 
following the last embedded blank in the name. This presents a 
problem for surnames containing blanks (e.g. Ten Kate); hence all 
such names are entered into the index twice, once under the full 
surname and once under the final part of the surname. In the 
author searches, all possible matches with the query name are 
recovered. For example, a search for author J. 3. Smith would 
find all references by James Brian Smith, John 3. Smith, J. 

Bruce Smith, etc., as well as J. B. Smith. A search for James B. 
Smith would find all references by J. B. Smith, James Smith, and 
J. Bruce Smith as well as James 3. Smith. 

The "title" search is in fact a title word search. In 
the example given, all citations with the word "classical" and 
"studies" but not the word "greek" in the title would be 
retrieved, regardless of the order of occurrence and regardless 



of whatever other words are contained in the titles of citations 
meeting those specifications. 

In both title and author searches the symbol # may be 
used to search for all words that match the preceding characters. 
For example, "title classical stud#" will locate titles 
containing the word classical and the word study or studies or 
studied or studying, or any other word beginning with the same 
four characters. The # sign must be preceded by a minimum of 
three contiguous characters. There is no provision for 
truncating suffixes to search for a series of common stems. That 
is, one cannot enter a search to find all "isms". A brief users 
guide card was prepared that summarizes commands and gives a 
sample session. Thi r r guide is in Appendix 5.5. 

In both title and author searches the string (title 
words or author name) being searched for must be enclosed in 
quotation marks when the phrase being searched contains a 
"reserved word" (such as title, author, or date) that is not 
intended to trigger parsing action. For instance, a searcher 
might wish to seek the author named "John Title," or the title, 
"Carbon Date." 

The syntax of this query language, as specified above, 
has the properties of a simple precedence grammar defined by 
Wirth and Weber <31>. it is parsed in a one-pass, 1 ef t-to-r i ght 
scan with a single push-down stack. A PL/1 program was developed 
to analyze the syntax (to make sure it has the simple precedence 
properties) and to parse the input of queries in such a language. 
This system, called SARPSIS (Syntax Analyzer, Parser, and 
Semantic Interpretation System), is primarily a consolidation of 
the work of Wirth and Weber and a translation of this work into 
PL/1. One advantage of having such a generalized syntax analyzer 
and parser is that it is relatively simple to change the query 
language. 



Complete documentation of SARPSIS, including listing of 
the PL/1 program, is contained in the BALLOTS quarterly report 
for the period ending June 26, 1969 <2>. 

A typical method of operation, is to alternate between 
the search and output options. A search sequence results in a 
set of accumulated references, after which it is desirable to see 
the contents of the located references. The user chooses the 
output option by issuing either of the following commands: 

type 

print 

When the user issues a "type" or "print" command, the system 
transmits to the appropriate device the contents of the 
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accumulated items. The results may be presented on the IBM 2741 
typewriter terminal or on an off-line printer. 

There are two basic formats for text presentation. The 
primary format includes data for six of the data elements 
contained' in a bibliographic item. These elements are: 

Author 

Title 

Af f i 1 i at i on 

Document Identification Number 
Number of pages 
Imprint date 

The second format includes data for the same six data elements 
plus all others contained in the item. The user selects the 
second format by issuing either of the commands: 

type extended 
print extended 

The user may preselect any combination of data elements 
to suit his convenience or the requirements of a given task. 

This is accomplished by issuing the "choose elements" command. 
All subsequent output is formulated according to this designated 
format until the user indicates that he is ready to go back to 
the default format or to specify another combination of data 
elements . 



There is also a command to the system with which a user 
can state problems he is having or make suggestions for improve- 
ment, These statements are collected in a data set arid printed 
out to the programming staff each week. This is one way in which 
the user becomes involved in the design of the system. 

2.9.3 An interactive search session 

Sample Searching Arguments using BALLOTS I Files 

COMMAND? spires 
*Welcome to SPIRES 
SEARCH? yes 

SUPPLY DATA COLLECTION NAME, D-C-N? ipf 
FIND? title intimate 
TITLE WORD SEARCH FOR... INTIMATE 
3 DOCUMENT(S) ACCUMULATED 
? t i enemy 

TITLE WORD SEARCH FOR... ENEMY 

1 DOCUMENT (S) ACCUMULATED 
? type extended 
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2977-2 

Bach, George Robert, 1914- Wyden, Peter, joint 
author 

The intimate enemy; how to fight fair in love and 
marriage 

PLACE/PUBL I SHER: New York; Morrow 
DATE; 1969 ... 

OPTION? restart 

FIND? a george bach and a peter wyden and ti intimate and @ 

? ti marriage and date after june 1968 
AUTHOR SEARCH FOR... GEORGE BACH 
AUTHOR SEARCH FOR... PETER WYDEN 
TITLE WORD SEARCH FOR... INTIMATE 
TITLE WORD SEARCH FOR... MARRIAGE 
DATE SEARCH FOR... AFTER JULY 1, 1968 
1 DOCUMENT (S ) ACCUMULATED 
? choose elements 
ELEMENTS? title, author 
ELEMENTS? date 
ELEMENTS? 

TO USE THIS FORMAT ENTER: TYPE OWN 
? type own 

TI The intimate enemy; how to fight fair in love and marriage. 

A Bach, George Robert, 1914- Wyden, Peter, joint author 

D 1969 

OPTION? restart 
FIND? id 2977-2 
ID SEARCH FOR... 2977-2 

1 DOCUMENT (S ) ACCUMULATED 
? type standard 

ID 2977-2 

A Bach, George Robert, 1914- Wyden, Peter, joint author 

TI The Intimate enemy; how to fight fair in love and marriage. 

ED 1st 

PP New York; Morrow 

D 1969 

ME a 

VI D 30 

PRO po 

ORD lc 

MR I lc; 9-20-70 

SHE Meyer 

PR $6.95 

PRE 1 

OPTION? restart 
FIND? a may 



ID; 

AUTHOR: 

TITLE: 



AUTHOR SEARCH FOR... MAY 

2 DOCUMENT (S) ACCUMULATED 
?d before 1920 
DATE SEARCH THRU 1919 

0 DOCUMENT (S ) ACCUMULATED 
BACKUP? yes 

SEARCH RESULTS RESET TO LAST 2 DOCUMENTS 

?d from 1919 thru 1967 

DATE SEARCH FROM JAM-1-1919 THRU 1967 

1 DOCUMENT (S) ACCUMULATED 
? type own 

T1 Spectroscopic tricks. 

A May, Leopold, comp. 

D 1963 

2.10 Prototype System Operation 

Input operations under the BALLOTS prototype system 
began in late February 1969, after a three-month experimental 
period spent in designing, appraising, and adjusting. 

The first task had been to establish the scope of the 
operations — l.e., the size and nature of the data base to be 
input. The character-set limitations of the IBM 2741 and the 
decision against trying to represent non-roman graphics 
automatically limited the data base to material that was already 
in the roman alphabet or that was customarily and regularly 
transliterated into the roman alphabet. It had been determined 
that approximately 30 percent of the Order Division's daily 
throughput of book requests could easily be accommodated, and 
this amount of material became the BALLOTS daily work load. The 
material included all science approval and purchase order 
material, all new standing orders, and a large segment of 
purchase orders going to Richard Abel and Co., Inc. 

The ability to create, from original input material, the 
data to be converted into organized record and index files 
depended on the success of several ther tasks. Cl) Ninety-seven 
data elements had been defined (see the Data element Handbook in 
Appendix 6.6). (2) Tags for the data elements had been defined. 

(3) A standard method of encoding material had been worked out. 

(4) Procedures for input had been defined. (5) A machine- 

controlled editing routine had been designed. (6) A humanly 
managed editing routine — l.e., proofreading — had also been 
designed. (7) Finally, encoders and terminal operators were 
tra i ned. 



Library processing under the prototype system included 
data coding, on-line input, file building and maintenance, batch 
processing, statistics keeping, and report generation. It seemed 



essential that all these activities be centralized in the library 
to maintain uniform procedures and control the flow of paper. 

For this purpose, two new library units were created in the 
Automation Department: Data Preparation and Data Control. The 

Data Control Unit was organized before the prototype 
implementation, having been established in advance to test 
BALLOTS data elements, forms, input procedures, and training 
methods. A file of 200 acquisition records had been built and 
used to test the data-base building and retrieval programs. The 
Data Preparation Unit evolved as a separate, well-defined 
activity as a result of the experience gained. 

2.10.1 Staffing and communication 

Specific production functions were identified and 
scheduled for the personnel borrowed from the acquisition and 
catalog departments. Response was at first gratifyingly 
enthusiastic. However, after six to eight weeks, supervisory 
staff in the contributing departments began to express some 
concern over employees' loss of time for their own tasks. This 
problem was alleviated to some extent by an agreement that the 
Automation Department would provide from its cwn budget for one 
full-time employee in each contributing Department to compensate 
for lost time. This was a good idea that did not work because of 
three other problems: 

1. Rating Employees - Rating the performance of contributed star 
became a problem, as not all supervisors ware willing 

to have their employees rated by someone else. The problem 
became acute in the case of one or two employees who performed 
much better as terminal operators or coders than they did as 
clerical assistants in their own Departments. 

2. Staff Loyalty - Divided loyalties interfered with the 
efficient management of employees' time and effort. When 
there were peak loads in the manual system, a "contributing" 
employee would often be withdrawn from his scheduled 
commitment to BALLOTS, 

3. Communication - Because people were borrowed from other 
Divisions, it was difficult to take more than 25 percent of any 
one person's time. Therefore, a greater number of people 

had to be involved. This in turn increased the amount of train- 
ing and made communication about changes in the system that much 
more difficult. This was a real problem, since the 
procedures in Data Control and Data Preparation were 
experimental and subject to frequent change and improvement. 

Not all problems centered about operations personnel. 
Communication with the Order Division on procedures to be 
followed in the prototype system was not satisfactory at the 



beginning. Many procedures were communicated orally at first; 
those communicated by memo were sometimes not sent to the 
appropriate people and confusion resulted. The production 
environment in the Order Division caused this confusion. Often 
supervisors were unavailable and communications were made 
directly tothe employees, whose automation work the supervisors 
were to review. To alleviate the problem, policy decisions and 
procedures were documented in the form of Library System Notes, 
wjlich were kept in a BALLOTS Data Control/Data Preparation 
Reference Manual in the Order Division.: This material was 

available to supervisors and employees. 



2.10.2 Training and text editor use 



All the personnel contributed by other departments were 
called Technical processing Assistants, a Stanford classification 
for beginning clerical staff receiving on-the-job training in 
bibliographic processes. Those from the Order Division were 
involved in pre-order acquis i t ion and bibliographic searching. 
Those from the Catalog Department were involved in bibliographic 
searching, added-copies work, or typing! headings on cards. Each 
employee in Data Preparation was trained in BALLOTS data element 
conventions, the flow of material into Data Preparation, vendor 
identification-number procedures, and the design of the coding 
sheet. Each employee in Data Control received training in Data 
Control procedures, the use of WYLBUR, (lata element mnemonics, 
interpretation of the coding sheet, proofreading techniques, and 
the flow of material into Data Control . j Each operator trained in 
these areas was able to perform the j ob 1 assigned . Those coders 
and input operators who were already familiar with Library of 
Congress bibliographic data had an edge 
and therefore were better able to resol v 



over the rest 
e problems. 



with a sign-on, a 
and responses by the 



user , 



A typical WYLBUR session begin$ 
combination of prompts from the system 

The main purpose of the sign-on is to pyt the user on-line, 
identify him to the system and to other ] users, and to facilitate 
the . account i ng of resource use. Following is a typical sign-on 
dialog; system response is always in upper case and the user 
customarily responds in lower case, though he may respond in 
upper case. 



STANFORD 3 05/14/70 09:34:56 

NAME? harrison 

ACCOUNT? XXX 

KEYWORD? XXX 

TERMINAL? w29 

COMMAND? 

The number following the word STANFORD identifies the 
communication line or "port 11 selected by the system for this 
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particular terminal during this terminal session. This number Is 
followed by the date and the time. The port number and the 
terminal Identification number enable users to communicate with 
other active terminals In. the system. The space to be occupied 
by the user's account number and keyword is automatically 
overwritten before this information is typed, to discourage 
account poaching by unauthorized users. 

Users accustomed to terminal operations usually act to 
shorten the system command prompt as soon as sign-on has been 
compl eted : 

COMMAND? set terse 
? 



Thus all later "prompts* 1 are in the form of a simple "?." At this 
point WYLBUR may be used for the following functions: 



1. Keying new data 

2. CHANGING data in previously keyed lines 

3. DELETING collected data 

4. SAVING collected data in a named data set 

5. USING previously defined data sets 

6. RUNNING programs stored under data set names 

7 . PRINTING edited 1 i s t i ngs either at the 2741 
terminal itself or offline on a high-speed 
printer. 

8. LISTING lines containing specified strings of 
characters . 

9. ACTIVATING the BALLGTS/SP I RES on-1 i ne. 
Interactive search facility. 

A case option permits input and output to be in upper 
and lower case. A WYLBUR session is terminated by the LOGOFF 
command. Upon sign-off, the user is furnished an accounting of 
his use of the following system resources or facilities: editing 
(CPU) time, compute time, memory usage (in page-seconds), I/O 
activity. Elapsed time is also given. 



Numerous other functions, such as simple arithmetic 
calculation, can be performed, but the entire capabilities of 
WYLBUR are beyond the scope of this report. WYLBUR is completely 
described in the WYLBUR Reference Manual <32>. Using WYLBUR to 
input bibliographic records is described in detail in subsection 
2.10.4. 



The following definitions were used for Data Control and 
Data Preparation: 

Coding - the preparation of data for input. This included 
assigning BALLOTS data element mnemonics to 

data to be input and supplying vendor identification numbers. 
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Editing - checking the accuracy, completeness, 
and legibility of the coding. 

Input - keying coded data into a machine- 

readable file on the IBM 2741 terminal, using WYLBUR. 

Proofreading - comparing a computer-produced 

printout against original coding sheets in order to note 

errors introduced during input. 

Correction - using WYLBUR to correct input 

errors before incorporating the record into the In Process 

File. 

Besides coding and editing. Data Preparation 
responsibilities included maintaining a mach i ne- readabl e Vendor 
name and address file used by the output printing programs. In 
addition to input, proofreading, and correction. Data Control was 
responsible for managing all acquisition file activities. This 
included running the SPIRES/ BALLOTS Data Base Building Program 
on a scheduled basis (using the Remote Job Entry facility of 
WYLBUR) and initiating the Purchase Order Output Print Program. 
File security was established by processing all In Process File 
updates in Data Control Department. 

2.10.3 Input procedures 

Input documents for encoding originated from two 
sources: material for which Library of Congress cataloging copy 
was available, and material for which no Library of Congress 
bibliographic data could be found. In the former case, a copy of 
the Library of Congress card was photocopied onto a blank coding 
sheet; in the latter case, a copy of the Library's standard book 
requisition form, SUL-25, was photocopied. This activity was 
performed by the Order Division secretary each morning. An 
average of thirty minutes per day were spent in this activity. 

The Photocopied coding sheets were sent to Data Preparation for 
coding and editing. 

Because of the large number of data elements, it was 
decided not to impose on the input operators the task of 
memorizing the tag for each data element. Nor were the data 
preparation staff asked to fill out grid forms to lay out 
precisely the content of a Data Element opposite its name. The 
use of grid forms was felt to be an unnecessary constraint. 

The fact that coding was being done without grid sheets for the 
Meyer Undergraduate Library book catalog keypunching was further 
evidence that the sheets would be unnecessary in the environment 
of the more flexible on-line terminal. 
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Input coding sheets arrived at the Data Preparation Unit 
by 9:00 a.m. dally. In the life of a record/ this was Day 1. 

Each piece of Information was tagged with a data element 
mnemonic. The coding sheet was divided Into three areas: 

Area 1: Preprinted Data Element Mnemonics 

Area 2: Request slip (form SUL-25) box and 
preprinted mnemonics 

Area 3: LC card box and blanks for mnemonics 

In Area 1, preprinted mnemonics were checked if applicable and 
coded values supplied if necessary. In Areas 2 and 3/ lines were 
drawn from a mnemonic to the data on the SUL-25 Request Slip, 
proofsliP/ or LC card as needed. (Examples of a blank and a 
completed BALLOTS input coding sheet are shown in Figures 10 and 
11. It quickly became apparent that the procedure of drawing in 
lines from the mnemonics to the data was not needed. _ After one 
week of inputting, most terminal operators were sufficiently 
familiar with the mnemonics and the data to interpret the coding 
sheet without the lines, and their use was soon discontinued. 

Any Library of Congress bibliographic data was coded by 
a coder from the Catalog Department, whose knowledge of such 
bibliographic data facilitated the operation. When an entire 
coding sheet was finished, the work was reviewed, usually by the 
Data Preparation Supervisor. Coding and editing times were 
recorded on each coding sheet. Whichever library division had 
produced the data on the coding sheet was responsible Tor the 
accuracy of that data. Suspected errors found by Data 
Preparation coders were discussed with the Chief Bibliographer or 
the Head of the Order Division; Data Preparation did not have the 
authority to change original data. Detailed Data Preparation 
procedures are given in Append x 6.5. 

Included in the coding process was the assignment of 
vendor identification numbers. As mentioned above. Data 
Preparation was responsible for maintaining a master 
machine-readable file of vendor Identification numbers, names, 
and addresses. Where possible, the vendor number used in the 
library manual system was used. Where no number existed, a 
number was assigned. This file was used by the Acquisition Print 
Program. Following this process for each vendor became 
burdensome; the procedure was changed so that only the 68 most 
frequently used vendors were assigned identification numbers, but 
the modified file still had to be maintained for change of 
address, etc. Appendix 6.5 contains an outline of procedures for 
modifying the vendor address file. 

Edited Input Coding Sheets, arranged in identification 
number sequence, were sent to Data Control by 5 p.rn. of Day 1 For 
input, proofreading, and incorporation into the In Process File. 
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Each process slip carried a unique identification number and was 
flagged in the Order File to indicate that the item was being 
processed through BALLOTS. The identification number of an In 
Process File record for which Library of Congress bibliographic 
data was input was included on the item’s catalog card to note 
the existence of a mach i ne- readabl e record. All subsequent 
activity against an item in the In Process File was reported to 
Data Control for file updating. On the morning of Day 2, Data 
Control input operators began to key coding sheets. 

2.10.4 Data input and update 

In using the IBM 2741 terminal and WYLBUR, the 
following conventions were observed: 

(1) The first line of each record must be the character string 
BEG I N 

BEGIN is preprinted on each coding sheet. 



! I (2) The last line of each record must be the character string 

! U 

! END 

1 -i 



r 

i 






END is preprinted on each coding sheet. 


i f 


1 


(3), 


--TnVe'' second line of data must be the identification 


s i. 

i 


J - 




n urnDe r • i ne numusr is vn i i ten on trie source uocuirien t 

xeroxed onto the coding sheet. 


! f 


] 


(4) 


Only one data element is permitted on each line. 


| L 
r 




(5) 


The input sequence must be: 


1 

[ 


] 

] 




Down Area 1 

Down the first column of Area 2 
Down the second column of Area 2 
Down the first column of Area 3 
Down the second column of Area 3 


[ 


3 




An tnput coding sheet marked with the proper input flow 
is shown in Figure 12. 


1 


1 


(S) 


Data must be input in the form 


L 


J 




<Data Element Mnemoni c>**<Val ue of Data Element>” 


i 






For example: 


i 


I 




a’/Gilmartin, Nelson W." 


li 

i o 
1 ERIC 


i 
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ID"300-6" 

BAC"NKW300" 



D 



0 
0 
0 

10 
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The use of quotation marks is a convention required 
by the build program. Sample records in input format 
are shown in Figure 13. 



( 7 ) 



( 8 ) 



Mnemonics are keyed 
used in the record, 
indicated. 



only for the data elements actually 
Data elements not used are not 



i s 



( 9 ) 



The WYLBUR, default line length of 72 characters 
used. If a data element exceeds one line, the 
quotation mark is omitted from the end of the first 
line. After a carriage return, the rest of the data is 
input beginning In character position 1, until all data 
is input. The last character is the double quotation 
mark. 

Data is keyed in upper and lower case using the 
WYLBUR upper- lower case option. 



Each terminal operator saved a day's input in 
data set on the IBM 2314 disc; each saved data set was 
according to the convention: 

BALLOTS. <operator ini tlal s>. <date> 



a WYLBUR 
named 



the input session, each operator listed out the 



At the end of 

data at the terminal for proofing. A proofreader (different from 
the input operator) proofread this listing against the original 
coding sheet, noting errors. After proofreading, the data set 
was corrected using WYLBUR. 



strung 

named 



At the end of Day 2, the 
the daily WYLBUR data sets 



Data Control Supervisor 
together into a master data set. 



BALLOTS. FINAL. <date>. 



The daily working data sets were then scratched. 

The master data set was converted to a format that could 
be searched at a terminal. This was done by submitting it to the 
data base build program. Records successfully processed by the 
program were added to the data base along with changes to the 
associated entries in the index files. Records not successfully 
processed were handled by the correction routine described below. 

It may well be asked why records are not input in a 
format immediately useful for machine searching. This question 
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X 

0 



begin / 
i d"5(>,of5“ 1" 

3. pro"po" 

4. aiid/'l" 

5. ord"lc" 

0 . a"Sliepard, Thomas, 1005-1043." 

7. t"Three Valuable Pieces. Viz. Select cases resolved 

•8. first principles of the oracles of vied; or. Sum of 

3 . ''Christian Rcl igi ori; ##rfoth corrected by four several 

10. - • editions: and a private diary; containing meditations 

11. and experiences never before published." 

12. eu"l’.opr i nt" 

13. pp"ilow York; Garrett" 

14. c! " 1 9 6 S " 

15. pr"$7. 50" 

16. buc"NKC001" 

17 . • sho"stk" 

la. mo "a 11 

IS. r t"3y Thomas Shepard£#wi th some account of the Rev. 

20 . Author. . . " 

21. s s i "(Amor i can Literature and Culture 1620-1820)" 

22. i mp"<Bos ton : Printed and sold by Rogers and Fowle 

23. in Queens t rent, 1747>" 

24. vid"30" 

25. f d"10-6-G0", 

2 6 . end ' 

2" . begin 

23. i d "6 04 2-1" 

29. pro"po" 

30. add"l" 

31. ord"lc" 

32. a"Rosenburg, Robert Kemper, 1920-" 

33. t"Choruses for Morning; Poems." 

34. pp"Bal t i more; Linden Press" 

.35. d"#1969" 

35. pr"$2. 75" 

37. bac"UKC001" 

38. she"stk" 

39. me "a" 

40. rri"F . Lynden" 

41. v i d"30" 

42. f d" 10- 6~ 69 " 

43. end 



Figure 13 

Sample Records in Input Format 



67 



Is often asked about the MARC Distribution Service, whose tapes 
are Issued In a "commun i cat i on s format" that must' be locally 
reprocessed for further use. The answer lies in the complexity 
of on-line search and retrieval software, which requires data to 
be expanded (or possibly even compacted) in ways too complex for 
human beings to transform and keyboard the data efficiently. It 
is simply more efficient to make the input operation as linear 
and perfectly straightforward as possible, and to assign to the 
computer all reprocessing and reformatting responsibilities. 
Transforming unprocessed bibliographic records via WYLBUR into 
searchable files is one of the largest and most complex programs 
In the BALLOTS system, for it simultaneously updates the master 
data base and creates the index files necessary for on-line 
searching. (The structure of these files is outlined in 
subsections 2.7.3 and 2.7,4.) Figure 14 shows the data sets used 
in prototype input and update operations. 

WYLBUR data sets exist in three formats: edit, card, and 
print. Every line of a WYLBUR data set in adit format is 
assigned a unique line number. At a normal terminal session, the 
edit format is always in use for collecting and modifying the 
data set. However, to change a WYLBUR data set into a BALLOTS I 
data set, capable of being processed by the data base BUILD 
program, it was necessary to change the edit format to the card 
format--a format in which line numbers are stripped off and the 
data stored as if it were a series of eighty-column card images. 
This is done with a single command to save the data set in card 
format. A card format master data set was created and the master 
data set in edit format was used as a back-up. Both were saved 
on different disk volumes under data set names 

BALLOTS. FINAL. <date> 

After a completely successful data base build run, the card 
format data set was scratched and a period was added to the edit 
format data set name to indicate that those records had been 
successfully built into the In Process File, thus: 

BALLOTS. FINAL. <date>. 

Data Base Build and Tape Dump programs were set up by 
the Data Control Supervisor. Using an automatic job control 
language (JCL) generator that prompted the user v/i th a series of 
consecutive questions, the Supervisor specified the programs arid 
files to be used, the appropriate run time, and the data 
sets to be input to the build program. The JCL generator 
provided a simplified way of setting up program runs, and 
allowed the system programmers to make JCL changes easily. 

A description of the automatic job control language generator, 
excerpted from the BALLOTS Third Quarter 1969 Progress Report to 
the Office of Education, is given in Appendix 6.5. 
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The Data Base Build Program was run overnight. After 
every sixty minutes of build time/ the entire in .Process File and 
Its Indexes were dumped onto tape as a back-up. Two tapes were 
used: one for every odd dump; the other for every even dump. 

This provided additional back-up In case of error or disk file 
destruction. The results of the build program were printed out 
and sent to the Data Control Supervisor. Records successfully 
added to the In Process File were listed.' Records that contained 
errors were listed with a diagnostic message explaining the 
errors. (See Appendix 6.5 for a list of diagnostic error 
messages . ) 

Data Control verified the nature of each error using 
these diagnostic error messages. The corresponding record in the 
edit format master data set was corrected. A card format data 
set of corrected records was created and named 

BALLOTS. CORRECT. <date> 

This data set was run through the Data Base Build Program along 
with new master data sets in the next run. When corrected 
records had been successfully incorporated into the In Process 
File/ the card format data set of corrections was scratched. 
Records still in error were run through the same process until 
accepted into the In Process File. 

As for update/ new or changed Information on items with 
In Process File records were noted in the Acquisition and Catalog 
Departments on either the Acquisition/Catalog Update Report form 
or the Cancellation Information Sheet. (Examples of these forms 
are included In Appendix 6.5.) These forms were collected daily 
by the Data Preparation Supervisor and reviev/ed for legibility 
and completeness. They were sent to Data Control on the same 
day/ arranged In identification-number sequence. 

The update program available during the prototype 
operation was on the entry level only. That is/ to update a 
record in the In Process File/ it was necessary first to delete 

the record in the in Process File and then to substitute an 

updated record in its place. To do this/ the record was first 

located in one of the master data sets in edit fornuit by using 

the data set indexes described below. The record was modified 
using WYLBUR. All records modified in a day were copied to a 
card format data set named 

BALLOTS.UPDATE. <date> 

Preceding the records in the data set was a series of commands to 
delete the old record in the In Process File. These update data 
sets were included in the next Data Base Build Program/ and were 
run along with new master and correction data sets. If an error 



In the updated record prevented Its being built Into the file, 
the correction routine described above was followed. After a 
completely successful build run, the update data set in card 
format was scratched. A period was added to the end of the data 
set in edit format to indicate that the records in the data set 
had been successfully added to the In Process File, thus: 

BALLOTS. UPDATE. <date>. 

The source documents for update reports and cancellations were 
f.’ed in iden t i f l cat i on-number sequence with the original Input 
Coding Sheet. 

The failure to develop an economical and rapidly 
executing update program at the data element level was a serious 
shortcoming of the BALLOTS I system. A consequence of this was 
the necessity of deleting an entire record and replacing it with 
a new record, which had to go through the whole routine of the 
Data Base Build Program just as if it were a newly added record. 
Numerous attempts were made to achieve update at the data element 
level, but all foundered on the complexity of the Data Base Build 
Program. 



The use of WYLBUR for updating was more expensive than 
originally anticipated. All input data sets that went through 
the Data Base Build Program were saved, in order to process 
subsequent updates. This resulted in a large number of master 
data sets. An index to all the master data sets was constructed, 
giving the data set name and line number for every record 
identification number that had been built into the In Process 
File. This index was created by a BALLOTS-devel oped program from 
all existing master data sets. Using WYLBUR, the operator would 
bring the index into core storage and give the command to scan 
the list for the ID number of the record to be updated. The 
command to scan in this way was: 

list ^identification number>' in all 

When the item was found, the data set name and line number of the 
record was printed out for the operator to see. The operator did 
this for each record to be updated and then proceeded with the 
updates. Scanning took a substantial number of machine cycles 
and was billed as "editing time" at the established rate for CPU 
time, $9.00 per minute. 

A less costly method was devised after several weeks' 
experience with the system. By running the index through an IBM 
sort-merge uti 1 i ty program, a printed list in identification 
number sequence was produced. This program was run initially to 
sort the existing index entries and was later used to merge, in 
sequence, any entries added to the index. 
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In summary. 



the WYLBUR data sets created In Data Control 



were: 

Informal Formal Data Set Name of volume 

Data Set Name Name where data set was 

> stored on IBM 2314 

1. Master Data Set BALLOTS . F I NAL . <Date> FILEA 

Card numbered format. This data set was used as Input 
to the Data Base Build Program. After a completely 
successful build run, this data set was scratched. 

2. Master Data Set - ” BALLOTS . F I NAL. <Date> FILEF 

Back-up 

Edit format. This data set was used as back-up and 
for all correction and update activities. The name 
was changed to BALLOTS. F I NAL. <Date> . after all records were 
successfully processed by the Build program. 

3. Daily Working BALLOTS. COperator's FILEG 

Data Set i n i t i al s> . <Date> 

Edit format, no back-up. Each input operator created a 
daily working data set for each day's input. After all 
daily data sets were concatenated into the master data 
set, each daily data set was scratched. 

4. Data Base Cor- BALLOTS. CORRECT. <Date> FILEA 

rection Data Set 

Card numbered format. Created as needed. Scratched 
after all records successfully incorporated into In 
Process File. 

5. Data Base Update BALLOTS. UPDATE. <Date> FILbA 

Data Set 

Card numbered format. Created as needed. Scratched 
after all records successfully deleted and added to 
I n Process File. 

The prototype system was activated in February 1969 and 
terminated in October of that year. By the end of the prototype 
implementation, over 6,000 records were being maintained in over 
100 WYLBUR master data sets in edit format. 

2.10.5 Printed Output 

The major of fl ine output In BALLOTS I was the universal 
bibliographic data form, which could be used as a purchase order. 
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claim, cancellation, notification to requester, catalog data slip 
(l.e., work slip), or notice to the National Program for 
Acquisition and Cataloging (NPAC). Catalog cards were not 
produced in BALLOTS I; the lack of file integrity on the IBM 
360/67 made this too much of a problem. Full particulars on the 
universal form and the programming for its production are 
contained in the BALLOTS Quarterly Report for the period ending 
June 26, 1969 <2>. Samples of the form appear in Appendix 6.5. 

2.10.6 Statistics and evaluation 

Of major interest in any new operations like Data 
Control and Data Preparation are the statistics collected on 
processing times, throughput volumes, and personnel performance. 
Collecting statistics was difficult, mainly because of the high 
turnover in borrowed staff and the lack of full-time supervision. 
These made training a seemingly never-ending task and a costly 
drain on the development staff's time. As a consequence, it was 
impossible to collect usable statistics in interesting areas such 
as : 

1. Throughput times for update processing and proofreading, 

2. Personnel time for functions such as data base building, 
file manipulation, or file back-up procedures, all of 
which were tasks performed by the WYLBUR remote job 
entry faci 1 i ty. 

3. Throughput times for correcting daily WYLBUR data sets. 

For a six-week sample period during May and June, 1969, 
the following production rates were tabulated: 



Records wi th 


acquisition, control. 


and LC 


bibl iographic data 


Function 


Mo. 1 terns 


Time 

(min.) 


Rate 

(mi n . / i tern) 


Cod i ng 


360 


1,115 


3.10 


Editing 


360 


514 


1.43 


Input 


360 


1,821 


5.06 


TOTAL 


360 


3,450 


9.59 


Records with 
data ( i .e . 


acquisition, control, 
, no LC data): 


and partial bibliographic 


Cod i ng 


427 


817 


1.91 


Editing 


427 


377 


.88 


Input 


427 


848 


1.99 


TOTAL 


427 


2,042 


4.78 
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The table shows, as might be expected, great differences in input 
rates between records having LC bibliographic data and those 
which did not. The average time to code, edit, and input a 
record with LC bibliographic data was a little more than twice 
the time needed for records with partial bibliographic data. 

Since the data element structure in 3ALL0TS I did not provide for 
subfield codes or delimiters, input times are not directly 
comparable with timings for MARC records given in the MARC Final 
Report <1>; however, input timings do appear to correspond with 
the experience of other libraries <14>. 



As the Data Preparation and Data Control staffs gained 
experience, the average elapsed time for coding, editing, and 
keying both types of records declined and finally leveled off at 
3.3 minutes per item. Total production during the final three 
months of prototype operations was as follows: 



Month 



Man-hou rs 
of di rect 
1 abor 



Records 

processed 



Average 
t i me/ record 



Approximate 
annual pro- 
duction rate 



August. 51.1 

September 45 

October 63 



839 3.6 min. 10,100 

818 3.3 min. 9,800 

1,144 3.3 min. 13,700 



Note that these figures apply only to direct labor time for 
input; supervisory time has not been included. Supervisory time 
for each of the three months was, respectively, 168, 167, and 184 
hours . 



Establishing Data Preparation and Data Control units as 
a centralized function seems to be effective and essential where 
typewriter terminals are the input device. But typewriter 
terminals are far from ideal for inputting highly formatted 
records of varying lengths. We believe that errors and input 
time can be significantly reduced by using CRT terminals for 
input. (See also sections 2.8 and 3.4.) 

Noise, speed, and display format were found to be the mdst 
Important limiting factors. Noise (especially in output) was signifi- 
cant even when sound shields were used. Both operators and the 
people working nearby found it distracting. Typewriter terminals 
scattered throughout the library in a production system would 
pose a worse problem. The speed limitation had three aspects. 

First, the carriage return time on the typewriter terminal is too 
long. Second, the time involved in the printing of the line numbers 
and prompts furnished by the text-editing system is too long. 

Because it would be too time-consuming to let the system automatically 
prompt for all possible data elements, the operator would have 
to enter the mnemonic for each data element actually input. 

Programmed on-line editorial checks of input become v i rtual 1 y 
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Impossible owing to the time required to print out error messages. 
Third/ the message length on the typewriter is not long enough: 
a maximum of 133 characters. A record keyed on the typewriter 
may Involve many computer interruptions. - (One keyed on a CRT 
terminal, which has a maximum message length of approximately 
1,000 characters--one screen, would Involve far fewer inter- 
ruptions.) Finally, the inability of the typewriter terminal 
to provide formats would practically force the operator to 
work from a prepared coding sheet. A CRT terminal that can 
display to the operator a complete, formatted page, that can 
print, at the rate of 1,000 words per minute (versus the 175 words 
per minute of the 2741 typewriter terminal), and that does so 
silently, is clearly a more desirable, people-oriented device. 

When prototype operations ceased in October 1969, 
considerable attention was given to the problem of designing CRT 
screens suitable for bibliographic input. The first decision 
made was to provide screen format recognition and on-line 
validity checks. Thus the computer would "know" the data 
elements on a given screen and what processing rules apply to 
each data element. Each screen could be fully edited when 
transmitted and appropriate diagnostic and error messages 
returned. This arrangement, now under development in BALLOTS II, 
will provide several advantages: a high degree of machine 

assistance for the operator; the ability to scan visually an 
entire page of bibliographic data at one time; more rapid input 
than on the typewriter terminal; reduction of errors in the data 
base owing to built-in editorial and diagnostic procedures; and 
elimination of the centralized input operations, with a 
consequent reduction in supervisory overhead. 



3.0 FINDINGS 



This chapter records our findings based on the 
experience in library analysis, design, programming, and 
operation gained with the on-line prototype system. The word 
"findings" is often used in describing the results of a discrete, 
controlled research project. It suggests quantitative data and 
statistical correlations. Developing and introducing an on-line 
computer system in a traditional service agency, such as a 
library, within an established institution, such as a university, 
is a complex process that is not subject to precise experimental 
control. There are few if any guidelines, and those who 
undertake such an effort are working with a mass of human and 
organizational variables. We share the perspective of Overmyer's 
<20, p. 2 7 2 > comprehensive library automation state-of-the-art 
rev i ew: 

This report also takes the position that the high cost 
of development has been of value. Planning, 
experimentation, testing, and evaluation are an 
unavoidable part of any carefully thought-out new 
endeavor. At some time and in some place these steps 
must be taken; if they are not, nothing but chaos 
and even greater expense are in sight. There has been 
waste and undoubtedly there has been a certain amount 
of "re invent ion of the wheel" while automation in 
libraries has been getting underway; but much of this 
has been unavoidable. In the absence of guidelines 
and a body of knowledge to lend support, libraries 
have had to engage in "trial and error." Experimentation 
and the use of new techniques take longer than 
establ i shed procedu res and inevitably increase costs. 

As communication improves and criteria are developed, 
hopefully more will be learned from the experience of 
others. 

BALLOTS I findings result from the prototype operation and their 
limitations are primarily the limitations in the implementation 
of that prototype. They are not conclusive in most cases. 

Indeed it is our hope that they will evoke questions, criticisms, 
and ideas on how to do better. We have learned from our own 
experience and it is our expectation that the reader of this 
report will see things that are not clear to us. 

3.1 Shared Facilities 

A gross estimate of the cost of the total implementation 
effort breaks down as follows; 

BALLOTS 1/3 

. SPIRES 1/3 

SHARED FACILITIES 1/3 
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Shared facilities consist of software and hardware designed to 
provide concurrent service to functionally related appl icat i ons. 
if each application user pays for his own development plus half 
of the shared facilities, he effectively gets the use of 57 
percent of the system for half the total investment. 

Alternatively, if two users invest similar amounts in independent 
development efforts, each is given substantially less for his 
money. Hardware economy of scale also applies here. If two 
users pool their resources to acquire shared hardware, the 
resulting capability will be greater than v/ould the capabilities 
of separate installations. This simple analysis argues for 
continuing combined development. 

3.2 Economy and File Integrity 

BALLOTS I has demonstrated the technical feasibility of 
computerized support for the bibliographic operations of the 
large library. Two constra i nts--one economic, the other 
techn i ca 1 --prevented the Stanford library from converting its 
prototype operations into a production system. These constraints 
stemmed from the nature of Stanford's IBM 360/67 service and the 
mission of the Campus Facility as defined in the period 1969-70. 

Two sections of computer memory are available for 
program^ execut i on at the Campus Facility. The first (high-speed 
batch) is approximately 100,000 bytes in size and accepts jobs 
lasting up to two minutes. The second (production batch) is 
approximately 300,000 bytes in size and accepts jobs of any 
duration. The prototype system uses the latter. A disadvantage 
of this arrangement is that while any other program is executing 
in the larger portion of memory, BALLOTS cannot, and vice versa. 
(Under the configuration existing in 1969-70 this precluded 
production use of Stanford's 360/57 by the library.) The Campus 
Facility's policy in this environment is to discourage long jobs 
by charging more per execution minute as the job progresses on 
the 360/67. A pricing structure (see the rate chart for the 
360/67, Appendix 6.2) has been established that rewards the person 
who submits a short, efficiently written and rapidly executing 
job and correspondingly penalizes jobs lacking such , 

characteristics. A further discrimination is made between day 
and night jobs; it is cheaper to run at night. It is clear that 
these policies are not to the benefit of a resident on-line file 
system. The BALLOTS System is, in effect, a single job that runs 
the entire day. According to the government-approved flexible 
pricing agreement (see subsection 2.4.2), there was no way 
Stanford could "wholesale" computer time to the library. All 
users had to be charged the same rates for the same resources. 

The problem is complicated by a lack of guaranteed 
access to the system from a terminal. There are over 200 
terminals connected to the system; about eighty can be in use 
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simultaneously. The 360/67 is currently approaching its capacity 
during periods of peak use. These periods occur near midterm and 
final examination time, or roughly eight times per year. During 
such Intervals the execution backlog grows long, and it is 
difficult to gain access to the system through a terminal. If 
the library's functions were supported on-line all day, fifteen 
to twenty of the eighty terminals could be tied up constantly. 

The technical constraint concerns file integrity. 
Stanford's software and procedures for Its IBM 360/67 are 
directed toward a rapid throughput, computation-oriented market. 
Although the data processing facilities provided are of excellent 
quality, a higher priority is placed on keeping the computational 
facilities operative for the entire group of users than on 
maintaining the capability of full file recovery. If a file 
failure occurs, correction must wait until a scheduled software 
maintenance interval. On the average, the Campus Facility's 
360/67 fails once every 36 hours, and sometimes more often. The 
incidence of failure may seem high to non-comput i ng peopl e, but 
realistically speaking, the system has excellent reliability for 
such a complex facility. Recovery from software failures is 
normally quite rapid--ten to fifteen minutes. (Hardware failures 
require more time to rectify and depend on the availability of 
parts and qualified service personnel.) Such failures, however, 
can cause unacceptable inconvenience to users of very large, 
continually updated library files. 

The recovery of files whose integrity has been lost in 
such situations is accomplished by periodically copying the file 
to disk or magnetic tape (dumping) and recopying it back to the 
disk (restoring) following a failure. Any changes made to the 
file since the last dump are lost, however. It has proved 
practical to dump a file after each hour of actual file building. 
But on Stanford's 360/67, dumps must he initiated by the user; 
they are not built into the system software. Because of the vast 
number of user files (over 60,000) and the fact that only the 
users can distinguish important from unimportant data, no attempt 
is made to provide audit trails and logging tapes that could 
enable the system to re-establish its precise status at the time 
of a failure with no loss of data. For the scientific community 
using a large, time-sharing system, this is not a severe problem. 
If the system fails and a program or small file is destroyed, it 
can easily be reinput and reprocessed when the system is again 
operational. But for the BALLOTS files this is a different 
matter. 

Considering all this, it seems clear that on-line 
bi b.l iographic' services’ should be provided in a computer 
environment that is intended for file-oriented applications, not 
just scientific computing. This is certainly true If production 
is being considered. However, the development work for library 
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automation and Information retrieval is exceedingly complex, and 
owing to the more ready availability of software talent in the 
large scientific center, it is believed that the system 
development work is more certain of success if conducted in the 
existing on-line scientific rather than an existing batch 
production environment. Oettinger <21, p. 126> has summarized the 
difficulties of performing development work on a computer 
intended mainly for administrative work: ' 

As many computer centers of all kinds 
have found out to their despair, routine 
scheduled administrative work and unpredictable 
experimental work coexist only very uneasily 
at best, and quite often to the serious 
detriment of both. 

It is important to note that there is nothing in the 360/67 
computer itself that precludes production operation. Adequate 
provision can be made in the software for file security, system 
reliability, and fast recovery. The operations environment can 
be production oriented. When this is accomplished, educational 
and research applications and production applications can coexist 
on the same configuration. The existing stock of peripheral 
equipment and system software must be modified, and cooperation 
is required between the library and the computer center. Use of 
the 360/67 for BALLOTS II production operation is now being 
worked out. It is expected that the necessary computing 
environment will be created to meet the library's production 
requi rements . 

3.3 Performance of On-Line Searching 

In BALLOTS I, two groups of operators and three groups of 
material were chosen for a test of the efficacy of the on-line searcl 
facility. Of the six operators who participated in the test, the 
first group were two members of the Project Sal lots staff and the 
second group were four members of technical processing 
departments. The groups of material to be searched were as 
follows: 



GROUP A: Request slips for books known to be on record in 
the In Process File. The searchers were requested not 
to use the record identification number to perform 
these searches. 

GROUP B: Unsearched request slips received in the 
Order Department the day before the searching 
experiment was conducted. The searchers 
had no assurance that corresponding records existed 
In the In Process File. 
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GROUP C: Unsearched, recently received approval 
books. Again, the searchers did not know whether 
corresponding records existed in the In Process File. 

Each searcher's work was observed and the time taken to conduct 
each search was noted. In the tables below, each operator is 
identified by a number. An asterisk preceding the number 
indicates a member a member of the BALLOTS staff. 



GROUP A SEARCHES 



Operator 


Total 1 terns 


Total Minutes 


Average Mi n 


Number 


Searched 


El apsed 


per Search 


*1 


16 


36 


2.25 


2 


5 


12 


2.40 


3 


3 


25 


8.34 


4 


4 


20 


5.00 


TOTAL 


28 


93 


3.32 


*1 


34 


63 


1.85 


2 


20 


26 


1.30 


3 


12 


21 


1.75 


5 


15 


25 


1.67 


*6 


13 


26 


2.00 


TOTAL 


94 


161 


1.71 


2-DAY TOTAL 


122 


254 


2.08 




GROUP B SEARCHES 




2 


18 


14 


.78 


3 


24 


17 


.71 


4 


21 


16. 


.76 


TOTAL 


63 


47 


.75 


2 


26 


31 


1.19 


3 


19 


15 


.78 


5 


9 


12 


1.33 


*6 


18 


30 


1.67 


TOTAL 


72 


88 


1.22 


2-DAY TOTAL 


135 


135 


1.00 



GROUP C SEARCHES 
(performed only on Day 2) 
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1.00 

1.27 
1.64 
1.30 

1.28 

The overall totals, for all operators and all typesof 
material, were: 

Total items searched 303 

Total elapsed minutes 448 

Average minutes per search 1.48 

The relatively long search times recorded on the first day were 
due to slow response time. This, in turn, was attributable to 
heavy demand on CPU cycles from all other partitions, all of 
which had priority for service. (The on-line search facility 
occupied the Production Batch of high-speed core. According to 
Stanford's IBM 360/67 scheduling algorithm, all other partitions 
except High-Speed Batch have prior call on CPU cycles. See 
subsection 2.4.2.) 

Fortunately, this situation did not persist on the 
second day. The shortest search times were those of operator 1, 
who had the most experience in conducting demonstrations and had 
practiced on an almost daily basis. All the other searchers were 
part-time users. 

3.4 Terminal Performance 

Even under the best circumstances (little competition 
for CPU cycles), the performance of any search facility is 
unimpressive when it is dependent on a typewriter terminal (See 
section 2.8 and subsection 2.10.6). The experience of BALLOTS I 
demonstrates the limitations of typewriter terminals for on-line 
searches. It takes long enough to type out the number of 
references satisfying the inquirer's search arguments. Should 
the user commit a syntactic error in the construction of his 
search, he is fortunate to receive a diagnostic message pointing 
out his error, but still he receives this message at the cost of 
his valuable time; and he must then reinput a corrected search. 
The most frustrating and time-consuming part of a search session 
with a typewriter terminal is, of course, waiting for results to 
be printed at the terminal. 

Noise is a further inconvenience. Faster mechanical 
devices are likely to be noiser and possibly less reliable, owing 
to the increased speed of the mechanical parts. Even the 
relatively cumbersome IBM 2260 is more than ten times faster in 
operation than the IBM 2741. We conclude that the use of 



2 14 14 

3 11 14 

5 11 18 

*6 10 13 

1 TOTAL 46 59 



typewriter terminals in any library production environment could 
never be entirely satisfactory, A fast: and flexible vjdeo 
terminal would aid in meeting the goals of bibliographic 
operations in the library. 

In this connection, it is useful to distinguish between 
the maximum character rate of a device and its useful throughput 
rate. The IBM 2741 typewriter terminal has a maximum character 
rate of 14.8 characters per second. Its throughput rate, work 
actually accomplished in a given unit of time, is considerably 
less because of carriage return time, the time taken to shift 
from lowercase to upper-case and hack again, and the time 
required to set up a new line. (The CRT terminal can output 
from 300 to 1,200 characters per second, depending on the model 
and the transmission line capacity.) Many other human factors 
and man-machine factors further reduce system throughput--such as 
the need to align forms in the typewriter and the operator's 
possible absence from the terminal at the time a system prompt 
arrives. Although some of these factors are: also present in CRT 
terminal use, removing the mechanical limitations greatly 
accelerates throughput. 

3.5 Staff and Resource Commitment 

The major components of institutional commitment to 
library automation have been reviewed and analyzed by Weber <29, 30i 
in two papers. A brief summary follows; the reader is referred 
to Weber ' s complete papers for further details. 

In the beginning, it seemed very clear to the Stanford 
Library that the computer support staff and systems analysts had 
underestimated the difficulty of creating an on-line system to 
support the library's complex bibliographic operations. What was 
not clear at first was that the library itself had also 
underestimated the difficulty of the task, as much as had its 
computer colleagues. 

Almost all the library functions dependon a complex 
combination of intellectual decisions and repetitive, clerical 1 
tasks. Librarians appreciated the conceptual complexity of their 
own professional tasks, but they had difficulty visualizing the 
depth of detail required to specify in full the tasks to be 
performed by the computer. This burden weighed most heavily on 
the professional library staff, many of whom were attempting for 
the first time to specify concisely and unambiguously the steps 
taken in bibliographic processing. It was the clerical and 
repetitive operations that were to receive computer assistance; 
this forced many librarians to immerse themselves in the dreary 
details of step-by-step descriptions of processes and functions, 
which would be handed over to the programming staff. 
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It was not easy to persuade some librarians that such 
detail was necessary; some were convinced that the mystical art 
of programming would fill in the gaps left in system description. 
Fortunately, the development staff was persistent and persuasive. 
Their tact and continued top-level support from the library 
administration made this difficult part of project development 
proceed with minimum dissension and maximum motivation. Our 
experience supports that of the report of the American Council 
of Learned Societies' Committee on Research Libraries <17, p. 65>: 

How can a good set of computer programs be created 
for libraries? They must be built up gradually by 
experimental development in an existing library. With 
focused objectives and effort, progress should be clear in 
a period of perhaps five years. Some programming 
experts must be brought into libraries but, more 
important, libraries must learn to use computers and 
must come to understand their streng-ths and limitations. 
This education process will take several years under the 
best conditions. From experience in other fields we 
can emphasize that there is no alternative to library 
experts learning computation. Any other course will 
lead to inferior results v/l th great waste of money 
and effort. 

Scheduling was another aspect of the system development 
process with which librarians were unfamiliar. Most technical 
processing librarians were familiar with the concept of the 
"event driven task." For librarians, the arrival of a book at a 
processing station, the work upon that book, and its departure to 
the next station were perfectly familiar events. But the 
professional staff did not associate any particular scheduling 
requirements with these events--books moved rapidly or slowly in 
accordance with their difficulty of processing. In the system 
development process, they were forced to survey many system 
components and mesh their own work assignments with those of many 
other persons. To do this effectively required the most detailed 
definition of tasks (this is what the Task Assignment Sheets were 
developed for) and the careful scheduling of tasks, so that 
procedures and processes could be developed on some realistic 
schedule. Most librarians requi red a period of intensive 
training and mental reorientation. Many persons soon got used to 
meeting deadlines, even if this meant working nights and 
weekends. After the initial shock of the reorientation, 
assignments were usually carried out with dispatch, and the 
librarians soon found themselves able to establish reasonably 
accurate task schedules and time estimates. 

As project activity accelerated in the course of 
production system development, it became apparent that members of 
the library staff would have to be assigned to temporary duty on 
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the project staff. It was difficult to convince department heads 
of the necessity for this, partly because of the persistent 
belief that the all-knowing computer and the system development 
staff could see to all the required details of system design 
(i.e., that a system could be designed for the user 'without the 
user's participation). Furthermore, it was .'ven more apparent 
that the persons assigned would have to be senior librarians of 
the departments to be affected by automation. Only these persons 
would have the many years of bibliographic experience and the 
broad policy views necessary to distinguish the important from 
the unimportant in the actual details of system work. In the 
end, the persons chosen for this active participation included 
the Assistant Chief of the Catalog Division, several senior 
librarians, and the Administrative Assistant to the Assistant 
Director for Bibliographic Operations. Many other full-time 
librarians were drafted for the automation effort. The Director 
of the University Libraries regularly contributed about 15 
percent of his time to BALLOTS. The involvement of al 1 these 
people means that the BALLOTS system will be designed WITH its 
users--an essential characteristic if the new production system 
is to serve those users effectively. 

The physical needs of a major development effort are not 
likely to be found In today's crowded libraries. Before the 
development staff moved t:o one location near the Computation 
Center, the library had provided three rooms, totaling some 1,600 
square feet in space, in its main building (which had been 
erected in 1919). Extensive alterations were needed to make this 
space suitable for the development effort. 

Essential to a software development effort is the 
staff's ability to maintain irregular hours— part icularl y because 
of the need to test and debug during off hours, when a system 
crash would not adversely affect other users of the Campus 
Facility's 360/67. Another need, hard to satisfy in the library 
building, is the demand for food and coffee, the latter almost 
being the programmer's life blood. Smoking is common among some 
programmers, and some will not take jobs where they cannot smoke. 
None of these requirements is readily met in any library > 

environment. Additionally, the heavy use of on-line terminals in 
program development produces a noise level intolerable in the 
library without expensive acoustic treatment. There seems to be 
no way to avoid creating special work conditions conducive to 
maximum performance from a system development staff. This in 
itself may require a major adjustment to be made in the personnel 
policies and physical plant of the library. 

3.6 Usefulness to Other Libraries 

Large system development, especially when undertaken 
with federa 1 funds, should be useful to as many libraries as 
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possible; this is the transferability cr i ter i on . that is a basis 
for funding grant proposals. Many specialists in library 
automation now recognize that transferability is a single term 
that masks a complex problem. Transferability refers not just to 
a whole system but to aspects of the system such as equipment, 
applications software, and procedures. It refers to the context 
within which the system was created; the design approach, for 
example, and management techniques. Transferability is a 
function of current computer technology and programming methods,, 

It is also a function of library standardization and cooperation. 
It is our belief that the problem of transferability is complex 
enough and of great enough Importance to warrant a separate 
research effort. The objective of this effort would be to 
pinpoint transferability characteristics and then to define 
factors associated with each of these characteristics that 
enhance or retard the likelihood of transferability. 

This section is an attempt, based on the BALLOTS 1 
experience, to begin such an analysis. An on-line library 
automation system is a complex of central computer equipment, 
input/display terminals, computer center operations procedures, 
systems software, applications software, 1 i brary . i nput, search 
and update procedures, and printed manuals. It is created by 
development techniques that include analysis, design, 
programming, and management. There are economic and manpower 
constraints in both development and operations. A system is 
developed and implemented within an existing library 
organization, (often) using an existing computer center. Such 
are, in general terms, the factors that affect the likelihood of 
transferring a library automation system In whole or in part from 
one library to another. For convenience wo group these factors 
into five levels: the system development level, the 
organizational level, the equipment level, the software level, 
and the library operations level. These conceptual levels are 
not hierarchical; they tend rather to intersect and overlap. As 
each level is discussed, we will indicate the way in which 
BALLOTS ! attempted to promote transferability and assess the 
extent of its success. Ways in which BALLOTS Jl is working to 
promote maximum transferability will also be discussed. 

3.6.1 System development level 

This level includes the techniques of analysis, design, 
programming, and implementation. It refers to substantive 
conceptual approaches as well as to ways of managing these 
activities. The factors that affect transferability are: the 
amount of implicit knowledge required by analysis tools (e.g. 
forms); the extent to which design work presents a solution 
without presenting a general characterization of the problem; the 
amount of documentation required and completed; the degree of 
informality in management procedures; the nature of task 
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definition (for example, is definition general without the 
necessary detail being added later? or is it spelled out but 
without thought for the overall development plan?). 

BALLOTS I system development methods were appropriate to 
prototype development but have 1 inii ted use for other 1 ibraries. 
Analysis forms were developed but detailed standards 
(instructions) for their use were not created. Much of the prob- 
lem statement in the design area remained in the pe rsona 1 . notes 
of designers and in unrecorded staff discussions. Specific 
design solutions were written up, but rarely along with 
alternatives for consideration. Management techniques tended to 
be of the loose, flexible kind found in most research projects in 
a university situation. The difference between the effort that 
produces a resea rch report and the effort that is required to 
produce an operating system was not recognized in day-by-day 
management techniques. This problem is not unique to BALLOTS. 

Its solution involves introducing some of the elements of 
management in business (which is directed toward developing 
profitable products and services) into the library and adapting 
them to the values of a non-profit service organization. 

BALLOTS II at its inception produced a documented system 
development plan, a project management process for task 
definition, assignment, coordination, and review, and a 
documentation plan that included requirements and implementation 
procedures. All of these are in writing and have been .made 
available on request to several library automation projects and 
major libraries in this country and abroad. In addition, some 
commercial organizations planning production retrieval 
applications have asked for material developed by BALLOTS. 

3.G.2 Organizational level 

This level concerns the characteristics of the library 
or library system that is the site of development. Clearly, a 
computer system is most easily transferred from one library to 
another that is similar in size, the nature of its collection, 
growth factors, and accessibility to computer facilities. in 
addition, a system, no matter how well designed, will not be 
transferable (except "in principle") to a library that does not 
recognize or is unwilling to change some of its present modes of 
operation as required (see section 3.7). 

One aspect of transferability is the explicitness of the 
originating library's requirements. This includes the ways in 
which the library modified its internal organization to put the 
system to better use and the way (l.e., review and approval) in 
which it insured that the system would serve its actual needs. 
BALLOTS lisa prototype system and is dependent on the 
originating library because of the amount of experimentation that 
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went Into its development. The library did organize a separate 
Automation Department at the same level as its Acquisition and 
Catalog Departments/ with subordinate data input and control 
units--a step that other libraries may find a valuable approach 
to centralizing responsibility and ensuring quality control. 
However/ the actual procedures used wore somewhat cumbersome/ and 
depended a great deal on the locally developed text editor. 

In planning for a production system/ the library has 
grouped its technical processing and automation departments under 
one senior library official who previously had major 
responsibility for automation. For BALLOTS II, a plan for 
documenting and approving the library’s production requirement 
was implemented. This will be a multivolume work approved by 
library department heads. It will specify in the most detailed 
way what the library needs in order to use a production system 
effect i vel y . 

3.6.3 Equipment level 

This level includes the type of central processing unit/ 
the size core storage, the type of secondary storage (tape or 
disk), and the range of peripheral devices (input and output), 
particularly those at the man-computer contact point-~i.e., the 
input/display terminals in the library.. Equipment is a major 
component in the transferability of a system. As with software, 
lack of standardization in the computer equipment industry 
seriously and adversely affects transferability. But computer 
manufacturers are rapidly moving in the direction o^ greater 
standardization. In the meantime, one must consider whether the 
same or similar basic equipment is used nationally; whether 
.equipment has comes from small local manufacturers with limited 
service or sales staff; and whether any manufacturer-supplied 
custom modifications are central to the system design. 

BALLOTS I used a standard model computer from a 
nationally known computer manufacturer. BALLOTS II will do the 
same. All pieces of peripheral equipment at Stanford are 
standard items. BALLOTS I examined terminal equipment developed 
by several vendors, but finally used highly reliable, production 
model typewriter terminals. BALLOTS II will use essentially the 
same central computer equipment. Terminals will be a video type, 
but those selected will come from a reliable manufacturer. They 
will meet general specifications for library bibliographic 
operations so that other libraries wi 1 1 be able to use the 
specifications and analysis produced by Stanford. In addition, 
the reliability experience of Stanford will be made available to 
other libraries. In spite of such attempts to make 
transferability as easy as possible at the equipment level, 
libraries should be aware that even with equipment from the same 
manufacturer, differences in configuration will affect ease of 
transferabi 1 i ty. 
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3.6.4 Software level 



This level includes the system software that allocates 
computer resources, provides communication links, and offers data 
manipulation services (e.g. text editing). It also includes 
applications software that edits, displays, searches, and prints 
out bibliographic data. Transf e rah i 1 i ty at this level is 
affected by the type of programming language chosen, the extent 
of software documentation, the degree of design generality, and 
How dependent the system is on locally developed software, which 
in turn may depend on a particular local computer configuration. 
In general, lack of s tanda rd i zat i on in commercially available 
software and programming languages has a major effect on 
transferabi 1 i ty. 

BALLOTS I used PL/1 and Basic Assembly Language. 

Both are widely used, and PL/1 has many self-documenting 
characteristics. Programs were documented but a common format or 
set of standards was not used. The Stanford Computation Center 
uses OS, a widely used set of IBM system software, but its 
time-sharing and text-editing software is locally developed. 
However, these pieces of software have been effectively 
transferred and are now in daily use at the National Institutes 
of Health in Bethesda, Maryland. For BALLOTS !!, a detailed set 
of programming documentation standards has been prepared. A 
well-known, fully documented, higher-level language will be used. 
Should a less well-known, machine-level language he used, it will 
be fully documented in its BALLOTS application. BALLOTS 
interface software will be fully documented so that transfer to 
another system requiring interface modification should be 
accomplished as easily as possible. BALLOTS I! will continue to 
use IBM/OS. 

Libraries considering the use of an on-line system 
developed elsewhere will also want to assess the degree of 
production on-line programming experience in their own computer 
center staff. This can best be done through discussions between 
the head librarian and the head of the computer center. 

3.6.5 Library operations level 

This level includes the procedures, forms, and staff 
training program for the day-to-day operations using the 
automation system. Transferability will be affected by how 
clearly and fully overall requirements are stated; by whether an 
overall set of procedures is designed to fullfll these 
requirements; by how clearly and fully the criteria for necessary 
forms are stated and used; by the amount of documentation of such 
requirements, procedures design, and forms criteria; and by the 
amount of formal training material that exists for training 
library staff in procedures and forms. 
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A modest number of procedures and forms were designed 
for BALLOTS I. One significant form is the universal 
bibliographic data form (see subsection 2.10.5)/ wh i ch can be 
used for computer-produced orders, claims/ and cancellations. 

This form has been requested by other libraries. Owing to the 
1 imi ted s i ze of the prototype operation/ BALLOTS I training was 
of an informal, day-to-day/ supervisory nature. Libraries should 
be aware that any sets of forms and orocedures are imbedded in 
the organization where they were developed. The criteria used 
and the lessons learned in designing and using the procedures and 
forms are their most transferable aspects. 

The detailed analysis that has established BALLOTS II 
library requirements has documented each manual procedure and 
each manua 1 -automated (i.e., a terminal is used) procedure in 
terms of its input, output, and skill requirements. This 
documentation is the basis for an integrated procedure design in 
which we begin by documenting current procedures in a preliminary 
analysis; then document procedure requirements in a. detailed 
analysis phase. While software and hardware problems and 
solutions are being explored in the general and detailed design 
phases, the procedures and forms for the library environment are 
also being designed. Also during the detailed design phase, 
personnel to be trained are identified, training sessions are 
planned, and training material is prepared. Training takes place 
during implementation and the effectiveness of the training, 
procedures, and forms is monitored during installation. 

3.7 The Human Side of System Development 

This section is placed last in chapter 3.0 not because 
it is last in importance, but because really it is of the 
greatest significance. Introducing an on-line system into a 
library for daily use is an experiment in planned change <25>. 

It is interesting to note that typewriters were not readily 
accepted in libraries even after their benefits were demonstrated 
<3>. Idany readers are aware that an on-line system (unlike a 
batch system) affects the moment- by-moment working hours of the 
library staff. Furthermore, it is not a passive piece of 
technology like a typewriter or telephone. It is responsive and 
interactive, and its value depends heavily on the use made of it. 
The interactive nature of an on-line system poses serious design 
problems; it poses even more serious human problems. 

The human problems stem from the need to involve library 
staff in computer system development and the potential adverse 
effect of development on individual and group satisfaction and 
achievement. Again, the comments of Overmyer's review 
<20, p. 247> are to the point: 



We may lament tlie limitations of the equipment, 
but we can know in advance exactly what it can and 
cannot do. We may consider the budget inadequate, 
but a firm figure does exist on which to formulate 
plans. But wi th people it can be a different story. 
People have the power to make or break a system, be 
it social, economic, or automation and the attitudes 
they bring to their jobs can have a great deal to do 
with the success or failure of an operation. 

The Stanford Library Administration and the development staff 
were aware of the crucial role that the library staff were 
playing in the creation of an effective library computer system. 
They were equally aware of the anxiety potential of such a role. 
Several approaches were (and are being) taken that provide 
maximum attention to human considerations. 

The first of these is open communication about what is 
being considered and how individual librarians can participate in 
shaping developments. Many members of the library staff 
participated in the early studies that led to the initial 
proposal. Regular reports on system development are made at the 
weekly library administrative conference meetings; minutes of 
these meeting are distributed to all offices in the library. At 
every series of orientation meetings for new library staff, the 
BALLOTS principal investigator has led a discussion on the 
library's automation work. The second approach was to recruit 
librarians with working library experience for the development 
staff. Other capable analysts with backgrounds in the humanities 
are part of the development team. This provides a common ground 
of professional experience and shared values that help keep the 
lines of communication open with the library staff. The third 
approach was the active participation oT librarians on the 
development team in the library's staff association, in the 
University-wide librarians' association, and i r. local chapters of 
professional library organizations. This gives concrete evidence 
of the development staff's dedication to 1 i b rar i ansh i p . 

Stanford faculty were drawn into the early phases of ■ 
BALLOTS I through an advisory committee (see section 2.2). 

Reports were also made to the University Committee on Libraries, 
which is composed of both faculty and students. Project BALLOTS 
newsletters were prepared and distributed to libraries, library 
schools, and a growing number of individual librarians. 

Write-ups were prepared for university publications. It is our 
belief that all existing channels of communication can be 
judiciously and effectively used to create an awareness of the 
library's efforts to improve its operations. The same restrained 
approach advocated in communication with the library staff (see 
below) has been found most useful in communication with the 
university community. 



Members of the library administration give continuing 
support to the automation effort, formally in meetings, but also 
informally in conversations. There have linen times when the 
enthusiasm and expectations for BALLOTS were unrealistically 
high, both about how much the system could do and about how soon 
it would be able to do it. It is our experience that library 
administrators and development staff must walk a fine line 
between saying too much about automation and saying too little. 

If there is a choice, we suggest erring on the side of 
emphasizing the difficulty of the task and the limitations of the 
system. 



As the prototype system moved into the library, it was 
demonstrated to the staff in small groups. The Data Preparation 
and Data Control units operated out of a room adjacent to the 
staff lounge. Maximum visibility was considered to be important. 
When the new operations seemed to affect the ongoing work o c a 
technical processing department, steps were taken to relieve the 
strain. Recall (see subsection 2.10.1) the help that Acquisition 
and Cataloging received in handling BALLOTS processing. 

One of the multiple benefits that can emerge from an 
automation development effort is an opportunity for the library 
to examine Itself. The introduction of a computer into the 
library may seem to solve many of the library's problems; at the 
same time it often brings to the surface other problems — people 
problems. It is inaccurate to blame the computer for all of the 
storm that can surround its introduction into the library. It 
does affect individuals and their individual work, work 
relationships, and the existing organizational structures. If 
people are d i ss;:t i sf 1 ed with what seem to be the trivial, boring, 
or dead-end aspects of their jobs, the computer will not 
necessarily solve this. Instead, some workers will cling even 
harder to the clerical aspects of their job with which they feel 
secure. Others will find doing repetitive typing at a terminal 
only slightly more interesting than doing it at a typewr i ter. If 
there are personality conflicts in a particular department, the 
presence of computer development, ‘when teamwork is so common, may 
provide more occasions for differences to occur. If there are > 
supervisory problems, the computer will not make them disappear. 
Computers cannot teach supervision or promote satisfying 
learning. Only peopl e — sjci 1 1 ed, sensitive people such as one 
finds in many 1 i b ra r i es--can do that. If library policy seems to 
the staff to place little value on staff development, on staff 
participation in management, and on the mutual flow of 
information up the administrative hierarchy as wo 11 as down, a 
computer system may well be received with skepticism, anxiety, 
and covert opposition. 

But automation CAN be the occasion, as we holt eve it has 
been at Stanford, to demonstrate the importance of the individual 
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librarian. It can provide the opportunity to relieve much of the 
tedious repetitive work that has been, up to this time, a 
necessary part of library operations. It can improve staff 
communication by giving people from different departments a 
chance to work together on common tasks. It can cause 
supervisors to take a fresh look at problems and to consider 
adopting some of the solutions that have been found useful in 
business, such as planning by objective. Automation can cause 
the library staff to question the current usefulness of forms, 
procedures and organizational structures developed to fulfill 
needs that have since changed. It can improve library 
administration by causing administrators to rethink the means and 
ends of a library service that must respond to the changing shape 
of university education. 

There is no substitute for the recognition of individual 
contributions to development work made by the library staff. The 
successful implementation of an on-line library system is 
primarily a tribute to the staff. The installation of a computer 
system can be an opportunity, as we have shown, to create a more 
human environment inside a library. In so doing the total 
effectiveness of the library is enhanced. its value as a primary 
source of humanistic knowledge is reaffirmed. 
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4.0 RECOMMENDATIONS 



This chapter contains recommendations derived from the 
development of an on-line prototype system for a large library. 
They are directed to university librarians who may be considering 
on-line system development; to others in the university 
community, such as computer specialists, who would be cooperating 
in such an effort; in particular, to the library staff whose 
contribution is indispensable in feasibility evaluation, system 
analysis, and operational effectiveness; to equipment 
manufacturers who will be designing equipment for library 
automation; and to the professional library community that is 
interested in improving the quality of library operations in all 
areas. Many of our conclusions may seem pessimistic or 
overwhelming to those who have had little or no contact with 
large on-line systems development. It is NOT our intention to be 
optimistic or pessimistic. It IS our intention to state as 
clearly and as completely as possible the key requirements, as we 
see them, for on-line library systems development <37>. Then 
individual libraries and individual librarians will have a better 
basis for making decisions. Knowing the pitfalls, knowing the 
problems, knowing what has not been done or has been done 
with less than maximum efficiency is a valuable sort of. 
knowl edge --per haps the most valuable. It is in this spirit that 
the following recommendations are presented. 

4.1 Feasibility Recommendation 

A LIBRARY CONSIDERING ON-LINE SYSTEM DEVELOPMENT SHOULD CONDUCT 
FEASIBILITY STUDIES THAT MAKE CLEAR THE ADVANTAGES AND 
DISADVANTAGES OF IN-HOUSE DEVELOPMENT, CONTRACTED DEVELOPMENT, 

AND A MIXTURE OF BOTH. 

Feasibility studies involve assessing the economic, 
technical, and other 1 ess. tang i b 1 e factors of development. There 
is a truism that given enough time and money anything can be 
accomplished in computer system development. Like most truisms, 
this one has little relation to the realities of organizational 
conditions. But even if feasibility studies were based on all , 
that could be asked for in the way of time and money, this is not 
sufficient. The library must look at itself, but it must also 
look at the others concerned. To what extent does the computer 
center have the willingness, peronnel, and experience to support 
on-line system development <33>? To what extent do. the faculty 
and students see this development as an attempt to improve 
service as opposed to another instance of creeping computer 
control. In looking at itself, the library must assess its own 
willingness to change, the attitudes o f its staff, and the 
priorities of its long-range development plan. In looking at 
commercial software products and services, the library must be 
able to assess the costs of developing these products and 
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services on its own. The library must be able, with the 
assistance of a consultant if necessary, to determine what 
additional costs and effort it would have to bear in installing 
an externally designed system. With either in-house or 
contracted development, the library must give careful 
consideration to concrete means for ensuring contractual 
technical, schedule, and cost performance and user approval of 
the system design. 

4.2 Economic Recommendation 

•'"'AT THE PRESENT TIME, THE COST OF DEVELOPING LARGE, ON-LINE 

1. LIBRARY SYSTEMS MUST BE SUPPORTED BY FUND I NG OUTSIDE THE 

■) LIBRARY'S OPERATING BUDGET. 

\ 

x Libraries wi 1 1 need to seek financial support for 

on-line system development from the university or from agencies 
outside the university. This requires a clear understanding of 
the purposes and potential value of on-line systems as well as of 
the difficulties and costs. it is usually necessary for the 
library to demonstrate concrete efforts to make internal changes 
to show that it would use the proposed system to the best 
advantage. Such changes may be more services, or higher levels 
of services, or both. Large-scale technological assistance to 
libraries is a fairly new concept to many head librarians. It is 
even newer to many university administrators, who may think that 
books and librarians are all that is needed to keep the. library 
operating smoothly. The library must be willing to review 
realistically the costs in its existing manual systems and to 
describe accurately the displaceable costs in the areas affected! 
by automation, if it wants to support the arguments for 
university investment. 

4.3 Management Recommendation 

ON-LINE SYSTEM DEVELOPMENT SHOULD HAVE PROFESSIONAL COMPUTER 
MANAGEMENT, UNDER THE POLICY DIRECTION OF THE. LIBRARY AMD SUBJECT 
TO ITS CONTINUING REVIEW AND APPROVAL. 

There are many more on-line systems in operation now 
than there were five years ago. The people developing them are 
more experienced and the systems in turn are growing more 
complex. Managerial experience in on-line production system 
development is almost never found in libraries and rarely in 
university computer centers. There is no substitute for an 
experienced manager to plan, control, coordinate, and take 
responsibility for an effort joining the library with the 
computer center. The search for such a manager may extend beyond 
the university community; an enthusiasm for the challenge of 
library automation and a willingness to learn about libraries are 
the essential personal attributes. Frequently, senior computer 
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center personnel are In a position to advise the library In 
assessing background and technical qualifications. A competent 
manager Is only one factor in making sure that the library gets 
the system it needs. Formal mechanisms are needed to maintain a 
user orientation, such as a policy committee, independent 
technical review, and written approval of all des ign documents. 

A capable manager will welcome such monitoring activities as 
evidence of concerted user involvement. 

4.4 Staffing Recommendation 

LIBRARIES CONS 1 DERI MG OH-LINE SYSTEMS SHOULD SECURE OR CONTRACT 
WITH TECHNICAL PERSONNEL HAVING ON-LINE EXPERIENCE, PREFERABLY IN 
SOME KIND OF BIBLIOGRAPHIC/RETRIEVAL APPLICATION. 

Developing an on-line production system is clearly a 
significantly different task from developing a batch system or 
developing an experimental or demonstration on-line system. To 
most librarians, computer experience is all of a piece and such 
differences do not seem important. For the reasons of on-line 
systems complexity mentioned above (in addition to the inherent 
complexity of the library application), differences in the 
computer experience of potential staff cannot be ignored. 
Contracting development work poses similar problems, although 
probably not of the same magnitude. The library is thus In the 
position of trying to assess technical credentials in another 
professional field. In addition to seeking assistance in the^ 
university computer center, the library may be able to determine 
the qualifications of a firm by contacting previous clients, 
especially libraries, and by asking the opinion of knowledgeable 
people in library professional organizations. 

4.5 Documentation Recommendation 

'DOCUMENTATION IS A PRIMARY DEVELOPMENT TASK, AND FUNDS, 
SPECIALIZED PERSONNEL, AMD FORMAL MANAGEMENT COMMITMENT ARE 
NEEDED FOR ITS ACCOMPLISHMENT. 

Documentation is a means o f controlling development 
costs, promoting user-oriented system development, and ensuring 
reliable production operations. There is abundant evidence in 
library automation activity <18, p. 50> and in the computer world 
generally <23, p. 11> that most documentation is either lacking 
or poorly done. Without a management commitment to 
documentation, supported by written standards, procedures, and 
personnel, the documentation output of library system development 
will continue to be unsatisfactory. The resulting system will be 
less useful to others and will incur higher operating costs due 
to the unsatisfactory documentation. The library must make 
specific and mandatory documentation requirements of its own 
development group or of an outside development group. 
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4.6 Equipment Recommendation 

SPECIFICATIONS FOR VIDEO (CRT) TERMINAL EQUIPMENT TO SUPPORT 
ON-LINE LIBRARY OPERATIONS SHOULD BE BROUGHT TO THE ATTENTION OF 
MANUFACTURERS. 

The limitations of typewriter terminal equipment became 
apparent during prototype operations. Several upper-/l owar-case 
video terminals have come on the market in the past year, but 
there is no evidence that the requirements of library operations 
have influenced the design of these terminals. The point of 
contact between the librarian and the computer system and 
eventually between the public user and the system is of vital 
importance. Early in system development a library should examine 
its terminal requirements and put them in writing to be sent to 
manufacturers. Specifications cannot be too detailed and at a 
minimum should cover physical characteristics such as screen 
size, operating characteristics such as editing capabilities, 
costs such as single unit and cluster prices, and performance 
characteristics such as transmission notes. 

4.7 National Planning Recommendation 

THE DEVELOPMENT OF LARGE ON-LINE LIBRARY SYSTEMS SHOULD BE 
PLANNED AND IMPLEMENTED ON A REGIONAL BASIS. 



The development of' a large, computerized, technical 
processing system is so complex that it should be done preferably 
at a limited number of libraries located throughout the country. 

A system developed at each of these centers could be shared in 
either of two ways: (1) by disseminating complete documentation 

so that a maximum amount of the design could be adapted for 
system development in other libraries, (2) by each center forming 
a consortium in which several libraries could use the services of 
a central system. We believe the second of these two 
alternatives is the more technically and economically .easible at 
this time. This feasibility is limited by telecommunications 
costs where distance is a factor and by coaxial cable or 
microwave requirements in applications that use visual displays. 
The second alternative could involve a commercial organization as 
the central system. In some parts of the country this may be 
des i r abl e . 



Either alternative in which a library is the central 
system requires a major marketing effort if the full benefit of 
system development is to be - shared. In other words, libraries 
considering on-line systems should be able to shop around and 
find full documentation on both of the approaches suggested 
above. The federal government should assist universities in 
marketing new technological systems developed with federal funds; 



this might be done by funding conferences for technical and 
administrative personnel/ training sessions for potent ial users/ 
demonstrations where a system is operating, and regional MARC 
center operations. 
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35. A comprehensive view of the impact of computing technology 
on library functions can be found in System Development 
Corporation's TECHNOLOGY AND LIBRARIES. Part ofthis report 
is given as chapter 7, "Some Problems and Potentials of ^ 
Technology as Applied to Library and ' I nformat ional Services/ 
in Knight and Nourse. 

36. BooZ/ Allen, Hamilton/ Inc.'s s tudy . desc r 1 bes many of the 
management problems of large libraries in responding to 
change in the university. 

37. Some readers may wish to compare our recommendations with 
those of BooZ/ Allen, Hamilton, Inc. (see pp. 29-31, 49 
of that study), especially in the data processing area. 

38. The Computation Center assumes all responsibility 
for procuring, installing, and changing the location 

of 2741 terminals, once the requesting unit has submitted 
an order. All equipment is the property of the Center and 
all is leased to the users at uniform rates. Users may buy 
their own 2741's if they desire, hut because of rapid develop- 
ments in terminals and the relatively high cost of the 
2741 (over $3,000), there have been practically no direct 
purchases by Stanford users. Project BALLOTS has not 
purchased any of the terminals. 

A typical terminal installation consists of three parts: 
the IBM 2741 terminal; an elongated work table the same 
height as the terminal; and data communication equipment. 

The work tables are not supplied by IBM and are made to order, 
it is practically impossible to work at a terminal without 
the custom-made table, which also serves to hold the data 
communication equipment. Either of two sorts of equipment 
may be used for data communication: the Bell System' s 105-A 
Dataphone, or an acoustic coupler. Both devices are in use 
at Stanford. They are equal in cost and the Computation 
Center Indicates that there is almost no difference in 
rel i abi 1 i ty . , 
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STATISTICS FOR THE YEAR 1969-70 



Table 1 ; Expenditures 





(a) 

Salaries' ' /, \ 

(Regular/Requisition) ' ' 






Supplies 










and 


Total 




Total 


Acquis it ions 


Binding 


Equipment 


University ($2, 104, 272 / 198 , 578 ) 


$ 1 , 024,019 


$153,034 


$ 586 , 549 ^ 


) $4,066,45; 


Libraries 


$2,302 ; ,850 










Increase over 


' 68-69 +4.8 $ 


+ 10 . 2 $ 


+10.6$ 


+ 10 . 9 $ 


+6.9$ 


Food Research 


(24,307/903) 


4,553 


1,638 


479 


~ 31,880 


Institute 


25,210 










Hoover Institution ( 608 , 896 / 28 , 518 ) 


185,844 


13,790 


71,661 


908,709 


Library 


637 , 4l4 










Jackson Library 


(180,607/25,523)^ 
. 206 , 130 w 


62,747 


10,000 


15,418 


294,295 


of Business 










Lane Medical 


(102,483/26,625) 


72,011 


17,959 


21,984 


241,062 


Library 


129,108 










Law Library 


(149, 333/12,041) 
161,374 


113,460 


9,432 


15,204 


299,470 


Linear Accelerator (82,902/ - ) 


36,926 


2,227 


8,681 


130,736 


Center Library 82,902 










TOTALS 


($ 3 , 252 , 800 / 292 , 188 ) 




$ 208,180 


$719,976 


$5,972,704 




$3,544,988 


$1,499,560 


Total Increase 
over X 968-69 


+6 % 


+6.1$ ' 


+ 8-..3 °!o 


+ 6 . 3 $ 


1 

+5.4$ 



I) Includes Staff Benefits 

t ^^Does not include Work Study 

^Includes $ 321,592 computer time and related supplies 
i and equipment expenses for automation 

^D'O'es not include salaries of serials record project, $27,775. 
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Table 4: Cataloging* 



Cards Pi 





New Titles 
Cataloged 


• Physical 
Items Newly 
Processed 


National 

Union 

Catalog 


University Libraries 


58,239 


72,493 


43,931 


Food Research Institute 


1,172 


1,172 


— 


Hoover Institution, 


18,361 


31,843 


10,593 


Jackson Business 


3,225 


6,336 


— 


Lane Medical 


2,506 


4,525 


89 


Law Library 


4,341 


13,390 


— 


Linear Accelerator Center 


6,428 


8,828 


- - - 


TOTALS 


94,272 


139,087 


54,613 


* Includes Books 


and Pamphlets, 


Microfilms, Microform Sheets, Phonorecord 



** Statistics not kept. 
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Table 4: 


Cataloging* 












Cards 


Prepared for 


the; 


New Titles 
Cataloged 


Physical 
Items Newly 
Processed 


National 

Union 

Catalog 


State 

Union 

Catalog 


Stanford 

Catalogs 


58,239 


72,493 


43,931 


6,306 


531,420 


1,172 


1,172 


— 


— 


** 


18,361 


31,843 


10,593 


6,550 


74,566 


3,225 


6,336 


— 


— 


24,879 


2,506 


4,525 


89 


— 


1,101 


4,341 


13,890 


— 


— 


34,840 


6,428 


8,828 


— 


— 


** 


94,272 


139,087 


54,613 


12,856 


666,806 



les Books and Pamphlets, Microfilms, Microform Sheets, Phonorecords , etc. 
sties not kept. *■' 
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Table 2 



Library Staff 



Librarians and Library 

other Professionals* Assistants * 


Casual 

Employees** 


Total 


University Libraries 


86.55 


173.83 


52.293 


312.673 


SP IRES /BALLOTS Project 


22.0 


2.0 


1.00 


25.00 


Food Research Institute 


1.0 


2.0 


.23 


3.23 


Hoover Institution 


29.0 


41.75 


9.25 


80.0 


Jackson Business 


9.3 


13.5 


.86 


29.66 


Lane Medical 


4.5 


13.0 


4.7 


22.2 


Law Library 


5.5 


14.75 


3.0 


23.25 


Linear Accelerator Center 


4.125 


5.125 


0 


9.25 


TOTALS 


161.975 


265.955 


77.333 


505.263 


* Actual 


numbers as of May 


31, 1970. 







** Full-time equivalents of personnel on salary requisitions. 



Table 3: Serial Titles Currently Received 

Other 





Newspapers 


Serials 


University Libraries 


71 * 


32,476 


Food Research Institute 


0 


709 


Hoover Institution 


346 


3,441 


Jackson Business 


31 


4,514 


j Lane Medical 


0 


2,581 


; Law Library 

1 


12 


4,611 


Linear Accelerator Center 


0 


616 


TOTALS 


46o 


48,948 



*In addition, the University has available the 157 

newspapers on microfilm that it cooperatively supports 
through the Association of Research Libraries. 
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Table 5: Growth and Extent of Resources, July 1, 1969 - June 



Volumes 



Microfilm Ree 



o 

00 



UNIVERSITY LIBRARIES 


Gross 


Net 




Net 


Main Library: 

Central Circulation Department: 


Increase 


Increase 


Total 


Increase 


Main Stack & Meyer Basement 


64,458 


11,844 


922,019 




Engineering Library 


2,898 


316 


55,524 


763 


General Reference Room 


2,359 


-3,072 


28,819 


— 


Government Document Department 


8,252 


8,252 


137,966 


— 


Jones Collection - Creative Writing 


— . 


— 


1,860 


— 


Microtext Collection 


--- 


— 


— 


1,501 


Newspaper Room 


3.4 


-96 


15,514 


— 


Special Collections 


5,467 


1,644 


72,605 


— 


University Archives 


715 


714 


9,i4i 


-- - 


SUBTOTAL 


84,163 


19,602 1 


,243,448 


2,264 


Art and Architecture 


61,150 


60,950 


60,950 




Asian Languages 


0 


0 


458 


— 


Branner Earth Sciences 


2,322 


2,296 


44,490 


— 


Briggs Memorial - English 


177 


177 


2,112 


— 


Chemical Engineering 


228 


223 


3,118 


--- 


Classics 


i4o 


i4o 


2,735 


— 


Communications 


217 


180 


3,397 


— 


Computer Science 


. 990 


863 


5,754 


— 


Cubberley Education 


2,590 


1,869 


74,036 


26 


Curriculum Library 


266 


218 


6,565 


— 


Dudley Herbarium 


233 


233 


8,160 


— 


Electrical Engineering-Solid State 


' 144 


-106 


2,643 


10 


Engineering Economics 


— 


— 


231 


— 


Falconer Biology 


2,058 


2,000 


30,735 


— 


Graduate Program in Humanities 


68 


68 


783 


— 


Guggenheim Radioscience 


205 


205 


2,012 


— 


Hansen Microwave Laboratories 


340 


340 


4,646 


- — 


Hopkins Marine Station 


1,321 


1,313 


16,259 




Mathematical Sciences 


1,759 


1,725 


21,627 


— = 


Auxiliary Collection 


13 


-265 


9,030 


mm m mm 


Memorial Church Library 


0 


0 


50 


mm mm mm 


Meyer Memorial Library 


8,686 


8,305 


99,601 


162 
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5 : Growth. 
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r 



nent: 

snt 



nent 

3 Writing 



\ 



id State 



ties 

ies 



O 




and Extent of Resources, 



July 1, 1969 - Jans 30, 1970 



Volumes Microfilm Reels Microtext Sheets & Cards 



Gross 


Net 




Net 




Net 




Increase 


Increase 


Total 


Increase 


Total 


Increase 


Total 


64,458 


11,844 


922,019 








... 


2,898 


316 


55,524 


763 


1,286 


623 


2,283 


£,359 


- 3,072 


28,819 


— 




— 


— 


8,252 


8,252 


137,966 


— 


— 


13,802 


151,229 


_ _ _ 


_ _ _ 


1,860 


_ _ - 


___ 




— 


... 


— 


— 


1,501 


27,501 


29,618 


285,144 


14 


-96 


15,514 


— 


— 


— 




5,467 


1,644 


72,605 


— 


— 


m mm 


— 


715 


714 


9 ,l 4 l 


— 


— 


— 


— 


84,163 


19,602 1 


, 243,448 


2,264 


28,787 


44,043 


438,656 


61,150 


60,950 


60,950 


- _ _ 


__ _ 




— 


0 


0 


458 






— 


— 


2,322 


2,296 


44,490 


— 


66 




— 


177 


177 


2,112 


— 


— 


— 




228 


223 


3,118 


— 


--- 


— 


— 


l 4 o 


l 4 o 


2,735 


— 


— 




— 


217 


180 


3,397 


— 


•— 


— 


— 


. 990 


863 


5,754 


— 


6 


132 


277 


2,590 


1,869 


74,036 


26 


365 


102 


482 


266 


218 


6,565 


- — 


— 


— 


— 


233 


233 


8,160 


— 


— 


— 


— 


' 144 


-106 


2,643 

231 

30,735 


10 


93 


— - 


— 


2,058 


2,000 











68 


68 


783 




— 


— 


— 


205 


205 


2,012 


— 


— 


— 


— 


340 


340 


4,646 


— 


— 


200 


1,700 


1,321 


. 1,313 


16,259 




9 . 




85 


1,759 


1,725 


21,627 


— 


4 


— 


— 


13 


-265 


9,030 


— 


— 


— 


— 


0 


0 


50 


-- - 


— 




— 


8,686 


8,305 


99,601 


162 


673 


— 


— 
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Modern European Languages 
Music (including Archive 
of Recorded Sound) 
Physical Education - Women 
Physics 

i Auxiliary Collection 

! Plasma Physics 

j Ryan Nuclear Technology 

1 Swain Chemistry 

Systematic Biology 
Tanner Memorial, Philosophy 
Timoshenko Collection 
j V. J. West Memorial, Political 

! Science 

i 

| SUBTOTAL 

o 

{ KD 

1 Stanford in Austria 

Stanford in Britain 
Stanford in France 
Stanford in Germany 
Stanford in Italy 
j Classical Center in Rome 

' Residence Hall Libraries on 

I Stanford Campus* 

TOTAL FOR UNIVERSITY LIBRARIES 
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Table 5: Continued 



Volumes 




Microfil 


Gross 


Net 




Net 


Increase 


Increase 


Total 


Increase 


35 


35 


1,010 


! 


2,997 


2,997 


25,793 


118 




— 


6,896 


— 


1,558 


1,532 


19,101 


— 


5 


-9,835 


2,843 


— 


85 


85 


997 




12 


12 


211 


— 


854 


849 


15,279 


— 


. 494 


494 


10,452 


— 


. 288 


138 


4,550 


— 


— 


— 


658 


-- 


114 


n4 


„5,26SL 


— 


173,512 


96,756 . 


1,735,899 


2,580 3 


183 


183 


2,609 




237 


237 


2,820 


— 


169 


169 


4,099 


— 


135 


135 


4,526 


— - 


258 


258 


3,683 


— 


134 


134 


1,425 


--- 


— 


514 


11,095 


•• 


174,628 


98^386 


1,766,156 


2,580 
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Table 52 


Cent Inued 










Volumes 




Microfilm Keels 


Microtext Sheets & Cards 


Gross 


Net 




Net 




Net - 




Increase 


Increase Total 


Increase Total 


Increase 


Total 


35 


35 


1,010 


— 


— 


— 


— 


2,997 


2,997 


25,793 

6,896 

19,101 


118 


443 


— - 


912 


1,558 


1,532 


— — 


_ _ _ , 


— MW 


. - 


5 


-9,835 


2,843 


— 


— 


— 


— 


85 


85 


997 


— 


— 


— 


— 


12 


12 


211 


— 


— 


--- 





854 


849 


15,279 


— 


— 


--- 





494 


494 


10,452 


— 


— 


— 


231 


288 


138 


4,550 

658 


mm ^ 
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114 


114 


5,269 


— — — 




w — — 


^ — m 


173,512 


96,756 


• 1,735,899 


2,580 


30,446 


44,477 


442,340 
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174,628 
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1,766,156 
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30,446 
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* See Table 5 A 
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! Table 5: Continued 



Volumes 

Gross Net 

COORDINATE LIBRARIES Increase Increase Total 



Food Research Institute 


1,681 


l,68l 


56,284 


Hoover Institution 


43,264 


43,246 


1,004,096 


Jackson Business 


10,974 


9,134 


153,574 


Lane Medical: Main 


7,125 


7,o47 


225,980 


Branches: Anatomy 


443 


443 


6,828 


Medical Microbiology 


192 


192 


4,337 


Law Library 


9,551 


8,955 


187,288 


Linear Accelerator Center 


6,478 


4,422 


42,829 


TOTAL FOR COORDINATE LIBRARIES 


79,707 


75,120 


1,681,216 


TOTAL FOR UNIVERSITY LIBRARIES 


174,628 


98,386 


1,766,156 


GRAND TOTAL 


254,335 


173,506 


3,447,372 
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Table 5: Continued 

Volumes 





Gross 


Net 






Increase 


Increase 


Total 


.e 


1,681 


• 1,681 


56,284 




43,264 


43,246 


1,004,096 




10,974 


9,134 


153,574 




7,125 


7,047 


225,980 




443 


443 


6,828 


r 


192 


192 


4,337 




9,551 


8,955 


187,288 


iter 


6 ? 478 


4,422 


42,829 


LIBRARIES 


79,707 


75,120 


1,681,216 


iIBRARIES 


174,628 


98,386 


1,766,156 




254,335 


173,506 


3,447,372 



Microfilm Reels Microtext Sheets & Cards 



Net 

Increase Total 


Net 

Increase 


Total 


755 

377 


27 

9,903 

1,293 

5 


21, 808 


55,336 


29 


860 


4,310 

2,499 


42,307 

27,108 


1,161 


12,088 


28,617 


124,751 


2,580 


30,446 


44,477 


4*.r2,340 


3>74l 


42,534 


73,094 


567,091 
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THE LIBRARIES OF STAMFORD UNIVERSITY 



STANFORD UNIVERSITY LIBRARIES 
Rl RLIDGRAPHi 0 OPERATIONS 
Acquisitions Department 

Binding and Finishing Division 
Exchange Division 
Gift Division 
Order D i s ion 
Serial Records Division 
Catalog Department 

Catalog Production and Maintenance 
Meyer and Overseas Division 
Monograph Division 
Serial Division 
Special Collections Division 
Special Materials Division 
CENTRAL SERVICES 

Circulation Department 
Financial Office 
General Reference Department 
Current Periodicals Service 
Reference Desk 
Asian Languages Library 
Briggs Library 
Classics Library 
Communications Library 
Graduate Program in the Humanities 
Memorial Church Library 
Modern European Languages Library 
Tanner Philosophy Library 
West Political Science Library 
Government Document Department 
Federal Documents 
Foreign Documents 
International Documents 
. State Documents 
II. S. Classification 
Microtext and Newspapers 
Special Collections Department 
Institute of American History 
Jones Library 
University Archives 

UNDERGRADUATE AND BRANCH LIBRARY SERVICES 
Art and Architecture Library 
Cubberley Education Lihrary 
Main Branch 




1 14 



129 



Women's P.E. Library 
Meyer Memorial Library 
Audio Division 
Audio Services 
Circulation Division 
Reference Division 
Music Library 
Music Library 
Archive of Recorded Sound 
Science Department 

Rranner Geology Library 
Computer Science Library 
Dudley Herbarium Library 
Engineering Library 
Main Branch 

Electrical Engineering/Solid State 
Engineering Economic PI ann i ng- L i b ra ry 
Guggenheim Aeronaut ics/ Rad i o Science 
Ryan Nuclear Technology Library 
Falconer Biology Library 
Main Branch 

Systematic Biology Library 
Math-Stat Library 
Physics Library 
Main Branch 

Hansen Microwave Lab Library 
Plasma Physics Library 
. Swain Chemistry Library 
Main Branch 

Chemical Engineering Library 
Hopkins Marine Station Library 
Inter-Library Loan 
Technical information Service 

COORDINATE LIBRARIES 

Food Research Institute Library 
Hoover Institution Library 
Jackson Library of Business 
Lane Medical Library 
Main Branch 
Anatomy Library 
Medical Microbiology Library 
Law Library 

Stanford Linear Accelerator Center Library 



6.2 Campus Facility Computer 



(referred to in subsections 

2.4.1 and 2.4.2 and in section 3-2) 

1. Campus Facility 360/67 
Machine Configuration 

2. Rate Chart for IBM 360/67 
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RATE CHART FOR IBM 360/67: 



ADDITIONAL 



SERVICE OR 
PRIORITY 


TIME 

LIMIT 


SERVICE 

CHARGE 


0-5m1 N 


5-10MIN 


10+MIN 


Emergency 


— 


$25 


■f 


$9/mi n 


$12/mln 


$16/mi n 


Urgent Short 


<5ml n 


$5 


4* 


$9/nii n 






Urgent Long 


>5mln 


$5 


♦ 


$9/ml n 


$12/ml n 


$16/mi n 


' Priori ty Short 


<5ml n 


$2.50 


♦ 


$9/ini n 






Priority Long 


>5ml n 


$2.50 


♦ 


$9/ml n 


$12/m! n 


$16/mi n 


Standard Short 


< lm i n 


- 




$9/mi n 






. Standard Long 


> lm 1 n. 


- 




$9 /ml n 


$ 12/ml n 


$ 16/m In 


Idle 


< lm i n 


- 




$4 /mi n 






Overn Ight 


none 


- 




$7 /mi n 


dec 1 ini r.g. 




High Speed 


none 


- 




$9/rni n 


$ 12/m i n 


$ 16/ini n 


Batch 
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6.3 Detailed Analysis Standards 
(referred to in subsection 2.5*3) 

1. Library Requirements Analysis Forms (DS. 100) 

2. Data Element Initital Description Form B“1 (DS. 101 ) 
3* Library Organization Form Fi-2 ( D S . 10 2) 

A. Training Requirements Form B-3 (DS. 103) 

5* Input Record Description Form B“4 (DS.104) 

6. Output Record Description Form B - 5 ( D S • 1 0 5 ) 

7. Internal Record Description Form B-6 (DS.106) 

8. Processing Rules Form B“7 (DS • 107) 

9* Interface Description Form B-8 (DS.108) 

10. Input Record Content Form B~9 (DS. 109) 

11. Internal Record Content Form B-10 (DS. 1 10) 

12. Performance Requirements Form B"ll (DS. 1 1 1) 

13* Control Requirements Form B - 1 2 (DS.112) 

14. Manual Procedure Abstract Form B-18 ( DS . 1 1 7 ) 



119 



134 



135 



l 





SPIRES/BALLOTS PROJECT 
DOCUMENTATION STANDARD 100 


1 Section 




Pt'KjO 1 


of 2 


J 


Lev; ( ) 


Rev ( x) 1 






Date 


6/23/7 y 


. TITLE: 


LIBRARY REQUIREMENTS ANALYSIS FORMS 




i 


PURPOSE. During Phase B of the System Development Process 
... ■ (See AS. ODD the operational requirements to be met by the 

i new manual -computer library system are established. These ■ 



requ i rements are stated precisely (quantat i vel y wherever 
possible) and in detail. Forms are a major tool in acquiring 
information for the establishment of library requirements. 








FORMS DESIGN. Necessary items of information are established, 
and forms are prepared for easy recording and display of this 
information. A Standard Is written for completing each form 
and a sample form is filed out v/i th information that is 
representative and comprehensive. These forms are pilot tested 
by the library analysis staff using the above Standards and samples 
as guides. The forms. Standards and samples are revised on the 
basis of pilot testing. Final versions are prepared by the 
Documentation Office. 

AVAILABILITY. Forms, standards and samples ore stored in the 
Documentation Office files marked FORMS and STANDARDS. The, 
are arranged by number wherever possible. The staff may ta<ce j 

whatever forms are needed. A "Restock Sheet" (S/C-7) is placed j 

near the end of every supply of a form. If a staff member 
finds this sheet, it is to be filled out and given to the j 

assistant in the Documentation Office. A copy of this form 
is attached. 



REVISION. Any proposed changes to a form, a Standard or a sample ! 
is submitted to the Documentation Office. It is reviewed with i 

the project management and if approved a revision is issued. j 

Revised forms are indicated by a "rev." before the date in tne ! 

form number. For example: The revision of the form B-4 (4-70) will Havt 

the form number, B-4 (rev. 5*70). | 

APPROVED FORMS AND STANDARDS. The following forms and standards j 

have been approved. • Each form has a sample. j 



B-I Data Element Initial Description 

DS.1.01 Standard for Data Element Description Form 

B-2 Library Organization Form Part 1 and 2 

DS.102 Standard for Library Organization Form Part 1 and 2 



B-3 

DS.103 



B-4 

DS.104 

B-5 

DS. 105 



Training Requirements 

Standard for Training Requirements Form 



Input Record Description 

Standard for input Record Description Form 
Output Record Descriptlo. 

Standard for Output Record Oesr r i nf i on Fnrn 



S/R-.2.-.05./7 f!V 



_1.2 0 



SPIRES/BAuLOTS PROJECT 


Sect \ on 


Page 2 of ?. 


Date 6/23/7^ )R(X'J 


TITLE: 



B-C Internal Record Description 

DS.IOB Standard for Internal Record Description Form 

B-7 Processing Rules 

DS.107 Standard for Processing Rules Form 

B-8 Interface Description 

DS.108 Instructions for Interface Description Form 

i 

B-9 Input Record Content 

DS.109 Instructions fori Input Record Content Form 

i 

B-10 Internal Record Content 

DS.110 Standard for Internal Record Content Form 

i 

B-ll Performance Requirements 

DS.lll Standard for Performance Requirements Form 

B-12 Control Requirements 

DS.112 Standard for Control Requirements Form 

B-13 File Summary 

B-14 Management Decisions 

B-15 Assumptions and Concepts 



( 



l 

i 

1 

I 

j 

i 

I 

i 

i 






B-16 . Assumptions and Concepts (Technical Processing) 

I 

B-17 Management. Decisions (Technical Processing) 

B-18 Manual Procedure Abstract 

DS.117 Standard for Manual Procedure Abstract Form 

j-19 Visual Display Format 
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SPl RES/BALLOTS PROJECT j 




DOCUMENTATION STANDARD DS.lOl 


Section 


Page ]. of ", 


* 3 


DateS/lD N( ) R ( : 






TITLE: 



DATA ELEMENT INITIAL DESCR I PT I ON FORM (ii-1) 



i ^ 



ii 

o 

n 

0 

x/ rj * 

ir 



INTRODUCTION' It is difficult to answer the question, 'What is 
a data element?' One example is the data element represent in& the 
author of a work. Is the data element, AUTHOR, (I.e. the entire 
designation of the author) or is it LAST NAME, or FIRST NAME, or 
MIDDLE INITIAL (*.e. part of the designation). How will you 
know if a data element stands alone or should be "broken down" 
into one or more c°"orate data elements? Further analysis is 
indicated if subelements could be referred to explicitly in: 

“ an input record 

- an output record 

- an internal record 

- a processing rule ‘ 

If real doubt exists, break it down. 

1. IDENTIFYING INFORMATION. Self-evident. 

2(a). STANDARD' NAME - A unique, common name used to refer 
to the data element. Insert a "break character" between words 
in STANDARD NAMES, e.g., Type--of--Payment . •! 

2(b). MNEMONIC - A 1,2, or 3 character alpha mnemonic 
for the data element. i 



3. DESCRIPTION - Give an example of the data 
labeling it EXAMPLE. Follow the example with a 
defining the meaning and use of the data elemen 
aliases if they compete with the STANDARD NAME, 
atypical or unusual instances under block 10. E 



element clearly 
short paragraph 
it. Include 
Put the 
KCEPT 1 ONS . 



4. . SUPER. ELSMENT(s) - If several data element!? form 
a hierarchical structure, super element - refers 
to the next higher element in the tree. 

R£coiv.o 




I 

.In the above figure. A, ii, and C are the highest 
level data elements In a record. Since our con- 
siderations are independent of records at this! time, 
we want to ignore that highest link. Thus, A, u, 

3 have A 
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SPIRES/BALLOTS PROJECT 
DOCUMENTATION STANDARD OS. 101 
/ 


Sect i on 


Pnr.c 2 of S 


Date S/15 N( )R( ) 


TITLE: DATA ELEMENT INITIAL DESCRIPTION FORM (ii-1) 



. j 






■ > 



L;i 



R 

ERjfc 



its subelements. 



5. 3U3ELEMENT (S ) 

List the sube 1 ernentS/ in the order in which they occur in the 
data element/ in the left column. Identify subelements for 
which there is a separate descriptor sheet by placing an 
aster ick (*) before the name. MULTIPLICITY refers to the 
number of times a subelement appears in a data element. Zero 
(0) is the lower boundary. 

Where possible/ give any syntax and ordering rules/ 

delimiters/ or initial and terminal characters. A syntax grammar 

composed of 3MF productions provides a means of expressing these. 



G. INTEGER/ OR DEC I 
is an integer or deci 
range/ number of poss 
whether distribution 
say, clustered). If 
range, indicate with 
number of possible va 
with 1 indet*. USE mu 
whether data element 
computation/ display/ 
will be displayed/ in 
the COBOL conventions 



MAL FRACTION - If the data element 
mai fraction/ then provide 
ible values/ and indicate 
is random (as opposed to, 
there exists no defined 
the word 'indet*. If 
lues is unknown/ indicate 
st also be indicated/ i.e./ 
wi 1 1 be used mostly for 
etc. If the data element 
dicate the edit picture using 



be 



7. CHARACTER STRING - If the data element is to 
treated os a character string (i.e./ never to be 
computed with and containing no coded information) 
first circle either fixed or variable length. If it is 
the latter/ estimate minimum/ maximum/ and average length. 

8. ALPHANUMERIC CODE/ OR LOGICAL POINTER - These 
two element types are treated together because 

the same questions are required of each. First 
indicate minimum/maximum length. If fixed in 
length/ the two will be equal. In the case 
where a reasonable upper limit exists (usually 
when the code is two characters or less, or 
when It is mnemonic in nature) values vs. meanings 
may be listed. In cases where this becomes 
unrealistic/ the code structure should be documented/ 
i.e./ broken down into components/ and the component 
value vs. meanings 1 i sted. In cases where the 
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SPIRES/BALLOTS PROJECT 




DOCUMENTATION STANDARD D3.101 


Section 


Page 3 of 3 




Date N( )R( : 


TITLE: DATA ELEMENT INITIAL DESCRIPTION FORM (3-1) 


< 

explanation is long and complex/ references to 
other documents may be given. 




9. CHARACTER SET. Indicate character set by circling 


one or 



0 

0 

0 

0 




ERIC 

.Imwijfermiii. 



more applicable abbreviations. NUM^numer i cal / SPEC=special 
characters such as punctuation/ $ signs etc./ UPC=upper case# 
L0WC=lower case/ DIA-diacri tical marks. 

10. EXCEPTIONS - It may be the case that all descriptors 
mentioned above apply only to some large subset of 
the total set of values. List any significant 
exceptions to these descriptors. 
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SPI RES/&ALLOTS PROJECT 
DOCUMENTATION STANDARD OS. 102 


Sect j on 


Page 1 of 2 


Date 5/5 N( >R( 1 


TITLE: LIBRARY ORGANIZATION FORM (B- 2) 



INTRODUCTION. During Phase 13, it is necessary' for library 
management to analyze and record personnel and organi zati onal 
changes which may be necessary to implement the manual - 
computer system. Personnel and <reorgan izati on are sensitive 
areas. However, for library management to efficiently prepare 
for training, testing and implementation, possibilities of 
of change must be considered early in system development. 




The Library Organization Form is a convenient, yet 
unstructured medium for recording changes which may be required 
to accomplish a particular subsystem, procedure or operation. 
Information on the form will be used to write the organization 
portion of the Requirements Document and also to prepare 
specific recommendations to management. The form is in two 
parts: personnel and organization. Guidelines for the use 

of each part follow. 

PERSONNEL. If no organization change is required, but personnel 
skills or the number of people required is in need of change, 
use Part I. Part I is in two parts: 1. Personnel Skills and 
2. Number of Personnel. 

1. PERSONNEL SKILLS. Under 1, state the personnel skills 
required for the job. Compare these skills with current personnel 
and assess the amount of over or under qualification. Be sure to 
evaluate separately the supervisor and worker skills required. 

If under qualified, describe the additional skills or experience 
necessary. Explore the possibility of filling the deficiency 
through a training program. (Cross reference your suggestions 
to the Training Requirements Forms.) if over qualified, explain 
to what degree.. If necessary, regard this form as project 
confidential and give specific names. 

2. NUMBER OF PERSONNEL. -Under 2, compare the number of people 
currently doing the job with the estimated number 

required. If additional personnel are needed, specify part 
time, full time or student employees. 



D 




ORGANIZATION. If an organizational change is required, use 
Part II. | 

CONDITION A: If a change to an already existing organizational 

unit is required, supply the following information: 




1. What is the current organization of the job 
of unit in question? How many people at . 
what levels are involved? 
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TITLE: LIBRARY ORGANIZATION FORM (B~ 2) 



CQ.ND i T I 
the fol 



2. What is the suggestion, for change? Is a change 
in the number or i eve] of personnel required? 

If SO/ specify. 

3. What is the reason behind the suggestion? 

. 4. What are the impl i cat i ons of the change? 

ON B: If a new organizational unit is required/ supply 

lowing information: 

1. What I s . the suggested organization of 

the new unit? Include information on the 
estimated numbers and levels of personnel 
required. 

2. Are any functions now performed by a 

library organization unit to be taken. over by this 
new unit. If so / describe the implications 
of th i s change. 

3. What, are the reasons for establishing a new unit? 
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SUBSYSTEM: ACQUISITION J»atk: 4/13/70 



i 



PAG JO 



3>R0CESS: SE RIAL PAYME NT || RE VISIO N: 

J! PROCEDURE: VOUCH I- R PR E P jj OPERATION.* 



i: 

1 s 
J [ op 

t 



k>'rrv<*r«ir|>«rt' , l< ■ m*nw 

° A..|sA-D.-l 



-b-A-j 



TT 



i|!— mirr* 

L_ ' 4— 









I ORGAN 1 7, AT ION 
I FORM 

j (PERSONNEL) 

I PER SONNET,: 

f PERSONNEL SHILLS: 

*1 

Current manual vouchor preparation for serial payments will virtually be 
eliminated with the conversion of the serial payment file to machine 
readable form and the implementation of the automated technical process- 
ing system. 

The new system will require (1) knowledge of how to search the Serial 
payment file (2) familiarity with the procedures of serial payment 
accounting and the contents of the file (3) knowledge of how to update 
the file and (4) knowledge of what the subsequent result of an update 
will be. I 

* j . 

Current personnel are aware of ;No. 2 above. Current personne T coul d be 
trained in the use of terminal *for searching, how to formulate updates, 
and how to, interpret the results of an update. 

The head of the Serials Record ;D I vi sion would have to be as intimately 
familiar with the automated serial payment system as the person 
responsible for day-to-day work. This could be accomplished with train- 
ing. j 

I . • 

Training Form Cross Reference: : Serial Payment file searching; updating; 
serial payment process ori entat ion (general );. acqui s i ti on subsystem 
orientation (general). 



NUMBER OF PERSONNEL: ; 

1. F.T.E. (library assistant) is currently used for search payment 
processing + .30 F.T.E. supervisory time. 

• The new system will require * j 

■ • i 

.75 F.T.E. (1 ibrary assistant-same level s . current system) + .20 
F.T.E. supervisory time. -.•V/fV 



* 

'1: 

|i 

h 



. jl.inUAUY 

! J ORGANIZATION 

15 

8 FORM 



L&viiM jeam 

;• 3 J.!.??A^:£^Li^CQua 5 JJAPn .Ij&tk: 4/13/7 0 

PROCESS: ORDERING 8 REVISION: 



* t PAGE 



i’* !•« 



1 



Morgan i nation) prockihjre:I pf updating ;} operation: 



y 









J OF 

J I 



■[ 



II ORGANIZATION: 
| ORGANIZATION: 
Condition B: 



SAMPLE 



•* wniwm. ft w*j « mu iMMntM vj^mwi) 



t/KMiMn.itoM'nifU 



1. A new unit/ called here Data Control, should be created to handle 
all I PF record creation and. updates, thereby relieving any Division on 
the Acquisition Department from coding or keying I PF data. 



The new unit would require 4 F.T.E. library assistant type terminal 
operators - 1 F.T.E. supervisory (library assistant - Group Supervisor). 

The unit could be remote from the Department but must ‘be in the same 
building. 



Data Control would assume responsibility for: coding; keying; 

"proofing; correction; output runs; diagnostic checking; output quality 
control; bursting and mailing; and, connunication with Data facility and 
programmers as wel 1 as library staff. 



I 2. 90% of all Order Division typing, H>% each of Dept and Exchange ! 

typing would be subsumed by Data Control. This means a clerical ! 

(library assistant) reduction of 4 F.T.E., for the Acquisition Department ; 
! (p.o. typists plus 1 F.T.E. searcher). jj 

3. Creation of Data Control would maximize control over Data entering ; 

the I PF, central i zed terminal skill in one area, and provide a single j 

I communication point In case ofj trouble. 
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TITLE; 



TRAINING REQUIREMENTS FORM (B-3) 



1. IDENTIFYING INFORMATION. Supply Che standard names for each 
level of analysis for which training requ i rements are given. 

2. TRAINING TOPIC. Supply the name or a short descriptive phrase 
for each skill or area In which training will be required. 

3(a) •. NUMBER OF PERSONNEL. Indicate the number of personnel who 
will need training. 

3(b). LEVEL. Indicate the level for each type of personnel to be 
trained. In most cases this will be the position designation or 
job t i tie. 

3(c). DEVELOPMENT PHASE. Indicate the Development Phase in which 
the training of each level of personnel will be completed. 

The Development Phases are: C. GENERAL DESIGN 

D. DETAILED DESIGN 

E. IMPLEMENTATION ' 

F. INSTALLATION 



0 



EXAMPLE 


OF 3(a), 3(b) 


and 3(c). 






TRAINING 


TOPIC 


NO. 


OF PERSONNEL LEVEL PHASE 


Computer 


terms 




4 


| Dept. Chief 


C 


II 


1* 




3 


i Supervisor 


C 


II 


11 




20 


| Assistant 


D 


II 


11 




7 


Librarian 


C 


Use of terminal 




1 


Supervisor 


C 


II It 


II 




75 . 


Ass i stant 


D 


II II 


'll 




2 


Student 


E 


II .11 


II 




9 


L i brar i an 


C 


4. EQUIPMENT REQU 11 


RED. 


List any 


equipment required 


for training 


such as 


slides, texts. 


reference 


material etc. 


5. COMME 


NTS. Make 


any 


add! tiona' 


comments regardin, 


g training 


requ 1 rementS/ for 


instance level i 


lof staff interest. 


avai 1 abi 1 it y 


of teaching aptitudes 


within the ! 


! staff or willingness to study 


outs ide 


of working 


hours. 

t . • . j 

" ' . ' • 1 

. i 


1 

|. . v • ■ 

1 . • 

I 

i • .. 


i, 




• • * ‘V *■' 




• • ... _ ; 
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Pago 1 of it 



Date 5 / 14 M( )R( 



[TITLE: INPUT RECORD DESCR I PT I Oi-1 FORM (13-4) 



The input records described by this form are In machine readable 
form. Various manual records which antedate the creation of the 
i machine input record are not considered. This form describes the 
, information contained in the input record/ but it does not describe 
j the format of this information. Examples of input records are: 
new bibliographic records captured from MARC for the IPF/ update 
records at time of material receipt/ and search requests. 

I. IDENTIFYING INFORMATION - Supply standard level designations. 

2a. NAME - The standard name of input record under discussion. 

2b. ID NUMBER - The unique identification number for the input 
record (Check the master numbering list). 

3* SUGGESTED INPUT DEVICE - e.g./ CRT/ typewriter terminal/ badge 
reader, etc. 

4. VOLUME - e.g./ 3/000 records/day; 4/000 lines/hour. Use unit 
and period most descriptive of input activity. Prefer records 
for unit. 

5. RECORD SIZE - including blanks and special characters input. 

6. INPUT SCHEDULE - e.g./ once a day (over night); constant (8-5 
M-F). This should have a logical relation to period in block 
4 . 

7. RETENTION - (a) Period refers to length of time a record 
will be retained/ usually in months &/or years. If it is 
to be kept until superceded/ list the number of generations (b). 

8. SOURCES - Source of the information in the input record/ e.g./ 
MARC tape; borrower ID card; Cataloging workslip. If there are 
multiple sources/ list all and indicate which information comes 
from which source. 

9. DESTINATION - The system# file, etc./ to which this record is 
input/ e.g./ IPF file. 

10. PURPOSE - The use of this record in the sytem. 

II. CONDITIONS CAUSING GENERATION - A list of ALL circumstances 
producing input record generation/ e.g./ a record will -be 
generated 1) when a patron charges a book/ 2) when the 
catalog department calls the book back for reclassification 
3) when the book is sent to repair/ etc. 

ACCEPT/REJECT CRITERIA - Conditions applying to the entire 
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INPUT 


SYSTEM: Techn i.cnl Process 


— r ■"-) 

"h* AUTHOR: 


n 




PAGE 


RECORD 


SUBSYSTEM: Cataloging 


( DATE: uJX 


5/70 






DESCRIPTION 


P R 0 C L S S : c.;\ t: n 1 or, P roc! uc t i 


fin | REVISION: i 






'OF 




PROCEDURE: „ pdnto 

7^-rtxr7l 'ttTu 1 - 


1 OPERAflQNjj 












I> 

0 



fn>. 



,(n ) NAME: HOLD TAPE RECORD 
SUGGESTED INPUT DEVICE: TAPE 



Cb) ID NUMg^.D- r.AT-v, 



VOLUME - (a) AVERAGE 
(b) PEAK 



1.500 

number 

2.500 

liumber 

•(c) GROWTH RATE NULL 



. r ecords 
"unit 



_ tecords 
'T~~^umT 



RECORD SIZE-AVERAGE: (a) 250 



10,000 

number characT ^pg ] number characters 

INPUT SCHEDULE: The Friday two weeks befonT^^e^eginni^^F eac h academic 
quarter. s 




quarter 



period 

quarter 



period 



RETENTlON-(a) Period: 



Average of_lfr v , ee ks 



(b) Number of Generations Retained: 



low long? 20 weeks 



SOURCES: Edit tape of keypunched input from Meyer Cata lo S«3 Division 

_ _ ' " — .pH 

DESTINATION: Meyer book catalog master tape 



PURPOSE: To update the book catalog master taj> e yith the n ew 
during the previous quarter. 



entries cataloged 



CONDITIONS CAUSING GENERATION: Each time a b 00 k Was c*tal 0 
a record was keypunched. These records were h^ tche( j ant the. 

The hold tape is input to the catalog update wh en it i s ti me /to create a new 
catalog or supplement. 1 



ged last quarter, < 
[tape updated monthly. 



ACCEPT/REJECT CRITERIA: 



1. Call numbers of records wwjst not duplicate call 

numbers already i n catalog. / 

2. Call number of c h^ nge and d^n-te records must match 
call numbers alr e ^ d y i n Cat *l >8. 



REJECT ACTION: 



1. Issue appropriate diagnostic 

2. Pass over record, continue Processing v** 



; h next record. 
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\ 

TITLE: OUTPUT RECORD DESCRIPTION FORM (B-5) 



0 

0 

G 

IT 



1 



Use this form to describe all output records from the automated 

system. Follow the description form with a format of the output, 

showing each character position and data element. 

1. IDENTIFYING INFORMATION - supply standard level designation 

2a. NAME - the standard name of the output record 

2b. ID NUMBER - the unique identification number for the output 
record. (Check the master numbering 1 i s t • > 

3. SUGGESTED OUTPUT MEDIUM - e.g., CRT, off-line printer 

4. VOLUME - e.g., 300 records/month; 4,000 lines/hour. Use 
the unit and period most descriptive of output activity. 

5. RECORD SIZE - e.g., 40 characters; 4 bits; 20 lines. Use unit 
most descriptive of output record. 

6. NUMBER OF COPIES - the number of copies which must be generated. 

7. OUTPUT SCHEDULE - e.g., once a day (overnight); constant 
(8-5 M-F). This should have a logical relation to period in 
block 4. 

8. OUTPUT SEQUENCE - e.g., call number order; alphabetical by main 
entry. 

9. RETENTION - (a) period refers to length of time a record will be 
retained, usually . in months &/or years. If it is to be kept 
until superceded, list the number of generations to be kept (b). 

10. SOURCES - The file, process, etc., from which this record is 
output. If there are multiple sources, list all and indicate 
which information comes ; from which source. 

11. DESTINATION - the system, file, etc. to which this record goes. 

12. PURPOSE -the use of this record. 

13. CRITERIA FOR GENERATION - a list of all circumstances producing 
input generation, e.g., •request to print purchase order, search 
of data field shows book to be overdue. \ 
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OUTPUT 


SYSTEM : CIRCULATION 


j AUTHOR: WED 




| PAGE 


i 

* i 


RECORD 


SUBSYSTEM ; 


I DATE: <1/13/70 


1 




DESCRIPTION 


PROCESS: CHARGING 


B REVISION 




OF 


1 i 




PROCEDURE n 4 ,\ A -rs i 


| OPERATION 









kLc, 



f(n’) NAME: NON-CIR. BOOK ERROR ■ MESSAGE 9(b) ID NUMBER: C0-<1I) 

| SUGGESTED OUTPUT MEDIUM: ON-LINE PRINTER 



VOLUME 




3 


recoras 


/ hour 


- QUJ AYhKAuiiii 


j^imber 


unit. 

records 


' . period 




\ U / sr JLiiXlX • " 

N GROWTH RATE • — 


number 
n i 1 


unit 


period 




\L/ v Hv it a n ivr* iu • 


number 


unit 


' period 


RECORD 


SIZE - (a} AVERAGE*- 




"j /u\ may TMUM • 


'/o •; 


u A ciii \ ft / at uivnviu • 


number 


unit 


number unit 


NUMBER 


OF COPIES: 1 








OUTPUT 
hours - 


SCHEDULE: Produced singly 

Sun: 1-llpm; M-F 8am-llpm; 


9 

at random during all 
SAT: 8am-6pm 


library service 


I 

P OUTPUT 


SEQUENCE: PRODUCED 


• SINGLY 







SOURCES : PROGRAM GENERATED 



DESTINATION: : PATRON AT TERMINAL 



PURPOSE: To inform patron that , the book he wishes to charge is a non-: 

circulating item. Also, “to provide information to the circulation 
librarian if the patron comes to him for further assistance 



CRITERIA FOR GENERATION JPatr on : is attempting .to charge: out a non-, 
circulating book.- This is determined when' the program checks the 

circulation class 1 in ' thA' linvAntnrv ''f i 1 a -fftw thA* hnnlr in 



iTf 









* 5 . 



circulation pj.ass‘ in the [inventory 'file “record for the' book i 

ques^iop;;: . 4 I ?■ ! " 

r ‘ i-i;-' '• i.. ■ : 

; r , V :;'v " •! 



• • J-- ' • f { l**.' 



m 



- ■ - *■ 
• i 



- v; ;\ 



* ! 



; i* •« 

— t *••• * ri'v V ■ SH ,# • “S' - : * : ■ . ■ * 

! ■; 1. , ■■ 1 .■ . 
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TITLE! NTERNAL RECORD DESCRIPTION FORM (B-6) 



Use this form to describe the anticipated machine readable files, 
jj 1. IDENTIFYING INFORMATION - Supply appropriate level designations. 
2a. NAME - The unique name of the; file. 

n i 

U 2b. ID NUMBER - The unique identification number of the file 
(check the master numbering list). 

[J 3.* SUGGESTED STORAGE MEDIUM: e.g., Tape, Disk, Drum, WYLBUR data set 

edit format, etc. 



)R< 



X > 



In 



4. ORGANIZATION: (a) SEQUENCE ORDER - e.g.. Author, Call number, ID number. 

(b) INDEXES.- The Index (i.e. entry point) files needed. 




VOLUME - e.g., 1,000 records; 500,000 characters. Use unit most 
descriptive of nature of the file (records are the prefered : 
unit whenever possible). Use period of growth most indicative 
of time frame in which additional storage capacity will be needed. 
For a constantly growing file, replace AVERAGE with PRESENT 
and omit peak unless there is a maximum upper limit. i 



RECORD SIZE - Including blanks and special characters input. 





D 



9. 




RETENTION - (a) Indicate the minimum, average and maximum life 
span of a typical record, (b) If one or more prior versions of 
the files are to be retained as backup or for an audit trail etc. 
specify the number of versions to be held, and the holding period. 
If a fixed number of volumes are rotated, i.e. write on oldest, 
read from youngest, then indicate 'rotate' under 'how long'. 

(c) If records deleted from the file are to be sent one level 
down in the storage hierarchy, e.g. to archival storage, or to 
some order processing file, then so indicate under 'disposition 
of record deletes'. 

INPUTS - A list of the standard names and ID numbers of ALL input 
records to this file. This list should' be backedup by Input 
Record Description Forms.. ' 

OUTPUTS - A list of the standard names and ID numbers of all output 
records from this file. This list should be backedup by Output 
Record Description Forms. 



f|Sl0. UPDATING: 




LEVEL - e.g.. Record; Data Element; Character 
MODE - e.g.. Batch; On-line (submission only, or 
submission/update) 

FREQUENCY -‘e.g., 1,000/day. Use period most Indicative 
of updating cycle. 
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Date 5/15 N(*)r( 3 


[ 


TITLE: INTERNAL RECORD DESCRIPTION FORM (H-61 




r 


i . • 

11. SEARCHING - Number refers to number of search requests. Use period 
most' Indicative of searching cycle, especially for maximum. 

I 


L 


12. USE PERIOD - The schedule of which this file must be 
searching and updating, e.g., .8-5 M-F. 

: . 


avai lable for 

j 

t 




t 
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INTERNAL 
RECORD j 

DESCRIPTION 1 

V 

r\ i 


[SYSTEM: Circulation' {AUTHOR: V/HD 


l SUBSYSTEM: l DATE: r ( /20/7n 


j PROCESS: !■ REVISION : 


! FILE NAME: Name & Address) FILE ID- CP- 3 


— * ^j?VC v 'VV V.fc£ -*» 



(page 

I OF 



2 i '(a) NAME: Patron. Name A Address 



I (h) IP NUMBER: CR-3 



| SUGGESTED S TORA GE MEDIUM: Disk, not permanently mounted 



li 

o 

a 



7 

J 



B 



ORGANIZATION: (a) Sequence Order; 

N/A 


(b) Indexes: 

Patron ID 


Number, Patron Name 






VOLUME: (a) Average 


15 f 000 


records / 


_ay_ear 




number 


unit / 


period 


(b) Peak 


20.000 


records / 


year 




number 


unit ' 


period 


i (c) Growth Rate 


. 300 


records / 


year 




•' numoer 


unit ' 


period | 


; RECORD SIZE: Average (a) 


50 


(b) Maximum 


80 j 




number 


characters 


number characters | 

- ^ 


RETENTION: (a) Record Lifespan: minimum 1 qt. average A year 


maximum 20 yrs i 



(b) Number of File Generations Retained: C 

(c) Disposition of Record Deletes : 



How long? 0 



a 

a 

tf 

0 

O' 



:U> 



INPUTS: 


Patron Records 
Patron Update Records 




OUTPUTS: 


Patron Lists 




■ 


Name & Address Records for Print Program 




UPDATING: (a) Level 


Data Element 


1 


(b) Mode 


Batch 


1 



(c) Frequency 


50 


/ 


week 1 




number 


/ 


period t 




SEARCHING: i (a) Average 


100 


/ 


day ! 


(b) Maximum 


number 

300 


/ 

7 


dSf 100 1 


T 


number ; 


/ 


period | 




{ USE PERIOD: (a) Searching 


Overnieh print run 




.. i 


rftn (b) Updating 


Once per week on overnight run 


i 
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Section 


Page 1 of 1 


Date 5/5 N’( )R( ; 


T,TLE: PROCESS ! MR RULES FORM (0-71 






0 

0 

D 

0 

0 

D 



Q 



0 



o 

U( 

. U.-J-l.— ■ .TI71 ■ 1 ■ 



Present rules either in narrative form/ as algorithms/ 
as equations/ or in decision table form. Equations 
and decision tables are the preferred form for clarity. 
Wherever a rule i s compl 1 cated/ include an example. 






uo 
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N 


i N 


Y 


N 
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SPIRES/BALLOTS PROJECT 
DOCUMENTATION STANDARD DS.103 


Sect 5 on 


Pago 1 of 1 


) _____ 


Date 5/18 N( )R( ) 



•' TITLE: INTERFACE DESCRIPTION FORM (B-8) 

1. FROM - the name of the system or organizational unit sending 
the record through the standard system level names where 

appl I cable. 

» TO • the name of the system or organizational unit receiving 
the record through the Interface. Use standard system names 
where appl Icabl e. 

2. RECORD NAME - the standard name of the record sent through 
i the interface. This will be an output record from the sending 

unit. A complete description of this record will be found on an 
Output Record Description Form. 

jj ID NUMBER - the unique Identification number for the record. 
Check the master numbering list. 

[3. MEDIUM OF TRANSFER - e.g., magnetic tape, punched cards, 
manual form. 

i .^4 . VOLUME - e.g., 1,000 records/day. Records is the preferred 
(J)nit. Use the period most descriptive of the interface activity. 

( 5. SCHEDULING - the cycling of Interface activity, e.g., over 
night; constant (8-5, M-F). 



6. SENDER CONTROLS - the edits, balances, totals, etc., 
maintained by the sender. 

7. RECEIVER CONTROLS - edits, balances, totals, etc., maintained 
by the receiver. 

8. RESOLUTION OF CONTROLS - necessary comparisons and checks 
between controls on either side of the interface. 



i INTERFACE 


[t'UOM 


|TO 


3 AUTHOR Way no D/ivlaon ! 


i PAGE ): 

! i 


DESCRIPTION 


jj Technical 
Processing 

* 


n Circulation 


| DATE 4/1.3 i 




II 

f; 


I REVISION ! 


! OT 
1 C b 


CAM Pi r- 



) l (a) RECORD NAME 



jj (b) XI) NUMBER Cl- 1.00 



> ) MEDIUM .OF TRANSFER Magnetic Tape 



I VOLUME - (a) AVERAGE: 
(b) MAXIMUM: 



50 



Records 



number 



200 



unit 

Records 



+ 



number 



unit 



~h 



(c) GROWTH RATE: . Constant 



number 



unit 



+ 



bay 



period 

Day 



period 



period 




s SENDER CONTROLS . Total record count 



L 



RECEIVER CONTROLS 



Total record 'count 



RESOLUTION OF CONTROLS Under program Control: 



.! 
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DOCUMENTATION STANDARD DS.109 


Sort \ on 




1 


Pago l of 


1 


N — — 


Date S/S 


n( )r( : 



TITLE: INPUT RECORD CONTENT FORM c 13-9 ) 



1. NAME - standard name of the input record. 

2. ID NUMBER - unique identification number for the input record. 
Check the master numbering list. ; 

i 

3. DATA ELEMENT - standard name of each data element which may 
be present in the record. 

L. SOURCE origin of the data element for this record/ e.g./ 
borrower ID card; invoice; IPF. 



5. MULTIPLICITY - how many times 



will this data element appear 



in this record. If variable/ give minimum/ average# and maximum. 

i 

5. EDIT RULES - ID numbers of processing rules which edit the 
inclusion of the data element in this record. If possible# 
include a brief description. j 






7. ACTION IF INVALID ~ action to 'be taken when edit rule stops 
input. 



8. STORAGE RULES - ID numbers of processing rules which affect 
the storage of the data element in this record. 
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Section 


Page 1 of 1 


Date 7 / 1 0 {j ( )R(x 


TITLE: ' INTERNAL RECORD CONTENT (B-10) 



1. NAME - standard name of the record. 



2, ID NUMBER - unique identification number of the record. 
Check master numbering list. 



3. DATA ELEMENT - standard names of all data elements stored In 
the record. There will be Data Element Description Sheets 
! for each of these data elements. 

j 4. SOURCE - document source* or file source (manual or 

i machine readable). Give I.D. number where applicable. 

j 5. MULTIPLICITY - the number of times, the data element may 

! occur in the record. 

. 6. ENTERED - point in the life of the record when this 

| data element is entered. 

7. UPDATE FREQUENCY - use the time unit which accurately 
I), reflects the rate of activity such as 12/w or 60/day 

or 200/mo or 10/yr. . 
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SPIRES/BALLOTS PROJECT 
DOCUMENTATION STANDARD DS.lll 


Section 


Page 1 of 1 


Date 575 N ( X . ) R ( ; 


TITLE: • PERFORMANCE REQUIREMENTS FORM 



I INTRODUCTION 



A method is given below for developing performance criteria 
for any system or system component. The source is the 
Management Information Systems Handbook (Matthes et al., 19G8). 



II OUTLINE FOR THE FORMULATION OF PERFORMANCE CRITERIA 

A. REVIEW OBJECTIVES - List the objectives of the new 
system in order of priority. 

B. DEFINE DETAILED OBJECTIVES --Determine which objectives 
can be quantified. Breakdown unquant i f i abl e objectives 
into simpler objectives which are all or in part 
measurable. Continue this subdivision until ALL 
objectives have been broken into elements which are 
measurable. 

e.g., dimensioned numbers: books, books per year (rates) 

books cataloged in 1972 
(performance) 

dimensionless numbers: books cataloged in 1971 (rates) 
(It may be necessary in some cases to break quantifiable 
objectives into simpler parts.) 

C. DETERMINE METHOD OF MEASUREMENT - Specify the procedure 
for measuring each detailed objective. These standards 
will insure that all measurements made in the monitoring 

.of performance over a period of time will be comparable. 

D. PREDICT FUTURE PERFORMANCE - Estimate the values of 
each detailed objective for a number of years. This 

will display the short: and long term goals for the system. 

III DOCUMENTATION OF PERFORMANCE REQUIREMENTS 



The Performance Requirements Form is used for collecting 
the output of the procedure given in Section II. 



O 
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DOCUMENTATION STANDARD DS.112, 


Section 


Page 1 of 3 


Date 5/G N( )R( 5 


TITLE: , CONTROL REQUIREMENTS FORM (3-12) 



b 



0 



D J 



o 

ERLC 



INTRODUCTION 

This documentation standard provides a form for specifying control 
procedures at any system level. A system control procedure must 
contain at minimum the three steps: 

A. MEASUREMENT - Some quantifiable aspect of the system 
is measured. # . 

3. COMPARISON - The measured quantity is compared i to a 
standard value. 



C. ACTION - An action is taken which 
to the result of the comparison. 



is appropriate to 



For example, it has been decided to monitor any change in the 
balance of the on-line Sook Fund File. One control point 
selected is in the ordering process within the Acquisition 
Subsystem. Mere, changes in fund balances occur when the funds 
are encumbered for book purchases. The steps in the control 
procedure are: 



A. 



3. 



C. 



(Measurement) The balance in a selected book fund is 
increased by the purchase price of a book just ordered. 



(Comparison) The 
budgeted for that 
year. i 



new balance 
fund at the 



is compared to the amount 
beginning of the fiscal 



(Action) If the' new balance is less than the budgeted 
amount, no action is taken. 3ut, if the new balance 
is equal to, or exceeds the budgeted quantity, a 
warning message ;is generated and displayed on the 
Acquisition Department Daily Operations Report. On 
the following day, the exhausted book fund is closed, 
and alternative jfunds are chosen for subsequent purchas- 
ing activi ty. ! 



The Control Requirements Form, shown on the next page, will aid 
the initial collection of similar control procedure data. 

The example described above has been entered to illustrate its 
use. Further instructions for completion of this form are given 
in Section II. ; 

I 

The form is intended to be general and may be used to describe: 
independent controls at isolated points in the system, networks 
of. interdependent controls which interlock control points 
within or across system levels, or the elements of control 
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Pago 2. of 3 



Date 5/5 N{ ) R ( 



TITLE: 



CONTROL REQUIREMENTS FORM ( 13-12) 



I I . 



ii 



n 



networks which may be elevated to system status e.g., cost 
accounting controls ===> cost accounting system; performance 
controls + statistics ==> management information system. However/ 
MAJOR system controls and control networks should also appear 
as entries in the Assumptions and Concepts List. 

A useful summary of types of controls and a checklist of common 
batch-processing control techniques can be found in Chapter 
6-5 of Hartman et al., MANAGEMENT INFORMATION SYSTEMS HAND300K 
( 1968 ) 

FORM COMPLETION INSTRUCTIONS 

A. CONTROL REQUIREMENTS FORM 

One copy of the form on the preceding page should be ised 
to document EACH Control Requirement. Complete EVERY block. 

3. FORM HEADER BLOCK 

Fill in AUTHOR and DATE if the requirement is being 
specified for the first time. Supply REVISION only if a 
previous version is being revised. 

C. REQ.NO. 

4 

Enter the unique identification number assigned to this 
Control Requirement. 

D. CONTROL POINT 

Locate the control point within the system by entering the 
name of the lowest system level containing the control point 
and those of all higher levels. If the point is a member 
of a control network/ include this network name beside NETWORK. 

E. CONTROL OBJECTIVE 

Describe briefly the constraints on system activities 
imposed by the control. 

F. QUANTITY MEASURED 

Identify the data element measured during the control procedure. 
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Section 


Pa ft e 3 of 3 


Oate 5/5 N( )R( 1 


] 

TITLE: CONTROL REQUIREMENTS FORM (3-12) * 



G. MEASUREMENT RULE . j 

i 

Supply an algorithm which gives a value for the data element 
name in F. Also specify the conditions which trigger 
execution of the algorithm. j. 

. 4 

H. COMPARISON STANDARD/RULE j 

Specify the comparison of the measured data element to 
a standard data element or value. 

I. ACTION BLOCK 



I 







The comparison can. produce only one of 
</-/>. however/ these can be combined 
condition sets: </=/>; </>; < >,; =/#. 
set and list each item under CONDITION 



three conditions: 
into 4 complementary 
Choose a condition 
in the form: 



Data Element Name 

(condition) 

of Measured Quantity 



Value or Data Element Name 
of standard Quantity 



For each cond i t ion listed supply: 



1. ALERT PROCEDURE 

A description of the data issued by the system to signal 
the control condition and the person/ group/ or system 
function that will be alerted: 

2. CORRECTION PROCEDURE 

A description of the action taken to correct the error 
condition or restore normal system activity. 
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* CONTROL 
j REQUIREMENTS 



rtnf^nj CtfiinvrKrunr* 



REQ. 

NO. 



. 



21 



*',«**•* ».t* t* * s^.-, m i f-j f«.» |,j a . < v-pi/ > « 

ii PAGE 



C_;^ r -”* 7 

SYSTEM LEVEL : LEVEL NAME 



[j- 



i7un#rw«* jr vm* -vr\ \Tr«v«r» tr\^m m ‘s *cr** ,■**-) v wrini m *•' rv \ 

CONTROL POINT 



"CAl't>t r 



AUTH OR: D » R» Mar tin 

> { os 

REVISION; A/6/70 

^1-14'AfJ.I Ife 14 •* - f . W I ITT £• IMWMWI 



e 

J. ON 



CONTROL OBJECTIVE 



\ SYSTEM : TECHNICAL PROCESSING 

f-r-. »»i *- 1 »■ mwi ii/r • * * j-» wt* n ntrr*««*«i i mmm * » 

J SUBSYSTEM: ACQUISITION 


1 PROCESS; 


ORDERING 


! PROCEDURE • 




| OPERATION : 




1 NETWORK : 


FINANCIAL 






QUANTITY : 
MEASURED : 


Any fund balance in th 



To prevent book fund balances from exceed- 
■ ing fund budgets. 



MEASUREMENT : When a fund balance changes during encumberment calculate: 
RULE 



New Fund Balance <*01d Fund Balance + Book Purchase Price 



S * 



.. d] 



COMPARISON : New Fund Balance: Budgeted Amount for Fund 

STANDARD/RULE • 



u 

p 

0 

u 

0 

i! 



) W 



f) 



CONDITION 



ALERT PROCEDURE 



CORRECTION PROCEDURE 



1. 



New Balanced Budgeted 
Amount ■ 



Direct Fund No., Fund Balance Close fund and update with 
and Budgeted Amounts, and- alternate fund pointers on 
System Msq. 43 ('Budget/. 



Exceeded') to acquisition- ; 
daily * \ . 

Operations Report (Rpt. Ii5) 



New.balance <Budgeted 
. Amount' 

i ' 

\ - 

■ .1 ■ 



No Action 



• f . 

i . 



i . 

i \ 



."i 
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the next processing run of 
AQ150. Reallocate budget 
overrun to alternate book 
fund. 

No Action • - ' 
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TITLE: 
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II 
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MANUAL PROCEDURE ABSTRACT FORM (B-18) 



1. IDENTIFYING INFORMATION - Supply standard level desig- 
nations including ID. 

PROCEDURE NAME - .Insert name and ID for procedure being 
described. 

ABSTRACT - A procedure abstract describes a manual procedure 
so that the flow of data 'and interfaces with related procedures 
are clear. It should be concise without omitting important 
information. 

I terns to be included in the procedure abstract are: 

1. Purpose of procedure. 

2. Personnel who carry out the procedure. 

3. Documents or data used (inputs). 

4. Documents or data produced (outputs). 

5. Equipment used/skills required, 

6. Files used. 

7. Frequency of performance. 
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MANUAL 

PROCEDURE 

ABSTRACT 



SYSTEM: tp 


AUTHOR: eam 


SUBSYSTEM: aq 


[ DATE: 7/14/70 ' 


PROCESS: 0rd 


REVISION: 6 / 12/70 




• 




2 



(a) (WE: 



Search Order File 



(b) ID KU1 BER: AQ.0RD.O3 



— Sample - 



ABSTRACT: 
1 , 



6 . 

7 . 



O 

ERIC- 



PURPOSE: The Order 

title is a 1 ready i n 
been ordered) . 



File is searched to determine if the requested 
process in the Order File (i.e., has already 



PERSONNEL: The searching is performed by library assistants 

from the Order and Serial Records Divisions RDP,- subject 
specialists and RDP Curators. 

DOCUMENTS USED: Manual forms include: Book Requisitions 

(AQ.SEL.BR01), marked PW/BN8 pages (AQ. SEL . PWO 1 ) , telegram con- 
formations (AQ. MO R . TCO 1 ) , and out of print offers (AW , M0P . 0PO 1 ) . 
See Input Record Description (B-4), on each of the above document 
for statistics. 

DATA PRODUCED: If the searcher finds that the' title is in the 

Order Fill, she will pull all 3x5 process slips except one, 
leave a cross reference from that Order File Record to the In 
Process File Record. A new IPF record will be input (AQ.0RD.14) 
consisting of l) bibliographic data, 2) old acquisition data 
from the order file, and 3) the new acquisition record. 



If the title is found,, and the order is 
and in added copy is not specified, the 
request and returns to' the quester. 



for the same location 
searcher annotates the 



If the title is not found, the searcher proceeds to AQ.0RD.Ol*. 

SKILLS REQUIRED: Knowledge of searching techniques and the con- 

struction and use of the Order File. 

Equipment used: none 

FILES USED: Order File 



FREQUENCY OF PERFORMANCE : Daily during initial implementation 

Will decline in frequency as the In Process File is used for 
orders. 
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6.4 Sample Documentation Standards 

(referred to in subsection 2.5.3 i 
and in sect i on 2 . 6) 

1. Naming/Numbering Conventions (DS.II3) 

2. System Flow Cha r ts-- Symbo 1 s and ( 
Conventions (DS.114) 

3. Name L i s t s --Sy s tern. Subsystem, Process? 
Files (DS.116) 

4. Assumptions and Concepts (B-15) and 
Management Decisions (B-l4) Samples 

5. Level I Subsystem Flow Chart ] 

6. Level II Process Flow Chart 



t 
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Page 1 of 3 


Date 5/25 N( )R(X ) 


TITLE: NAMING/NUMBERING CONVENTIONS 



I . SYSTEM LEVELS 



) 



4 

1 



1 2 ! ; j 

model A.OT.fe.'NN'.m 
e.g. 

1 . 



I JL L 

B.CR. 1 Cl .02.11 



SUPER-SYSTEM, a single alpha character code. 

The designation must be unique among all 
Data Facility systems.' (This element is optional for 
internal documentation^ but mandatory for external 
documentat ion . ) 
e.g. B - BALLOTS 

2. SYSTEM or SUBSYSTEM, a two character 
mnemonic. The mnenomic must be unique within 
the Super-System. Use either a system code 
or a subsystem code, but not both. 

e.g. ,CR ** Circulation System 

,AQ « Acquisition Subsystem 

3. PROCESS, a three alpha character mnemonic. The 
mnemonic should be unique v/ithin the Super-System 
if possible. it must be unique within the System 
e.g. . ICI » Initial Check-In Process 

4. PROCEDURE, a number from .01 to .99 assigned 
sequentially v/ithin a Process. Numbers from 

.01 to .09 should be written with a leading zero, 
e.g. .02 B Shelving Procedure (the second 

Procedure within the Initial Check-In 
Process 

5. OPERATION,. a number from .01 to .99 assigned 
sequentially within a Procedure. Numbers from 

'.01 to .99 should be v/ritten with a leading zero, 
e.g. .11 - Call Number Verification Operation 
(the eleventh Operation v/ithin the 
Shelving Procedure) 

Vlhen numbering a process, for example, do not use the 

Procedure and Operations elements. System levels below 

Operation are indicated by appending additional numbers, 

following the pattern for Procedures and Operations. 
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SPt RES/BALLOTS PROJECT 



DOCUMENTATION STANDARD DS.113 



-S ect Ion. 



Page 2 of 3 



Dc) to 5/25 N ( )R( X ) 



TITLE: NAMII NO/NUMBERI NO CONVENTIONS 



0 






II. IN PUT/ OUT PUT 

12 3 4 

i i, ;L i 

model A.M.AAA/MNlT 
e.g. B.CR.CHG.DS01 

1. SUPER-SYSTEM (same as, 



above ) 




[ 

i 




2. SYSTEM or SUBSYSTEM (same as above) 

3. PROCESS (same as above) 

4. INPUT/OUTPUT, a two character alpha mnemonic followed 
by two digits, 01 to 99, to differentiate separate 
occurences of the same record format. 

e.g. A. AA.AAA.AANN 
B.AQ.ORD. I P03 

Numbers from 01 to 09, should be written with a 
leading zero. In all cases the label, from 
super-system through the I/O mnemonic, remains the 
same as that given to. the initial occurence of 
the record format. 



I I I . FILES 

12 3 

ILU 

model AAAAAA 
e.g'. BTPIPF 




Unlike the identification for I/O and System 
Levels, the identification for Files always 
has a fixed length of six characters and 
never contains any special characters. 

1. SUPER-SYSTEM (same as above) 

2. SYSTEM or SUBSYSTEM (same as above, except that 

is omitted) 

3. FILE, a three character mnemonic. This 
mnemonic must be unique within* the system. • 
e.g. 1 PF B In Process File. 



: 
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DOCUMENTATION STANDARD DS.113 


Page 3 of 3 




1 


Date 6/3 N< )R( 


TITLE: NAMING/NUMBERING CONVENTIONS 



IV. INTERFACES 

12 3 1*2* 3 1 

l k jL, l k, U, ' 

model A.AA.AAA/A. AA.AAA 
e.g. B.CT.MEY/B.CR. ICI 

Interfaces are named and described by the 
sender. The name of the ' i nterface consists of the 
designations of the processes (see I. above) on 
either side of the interface. Interfaces are 
described in Form B-8. 

1. SUPER-SYSTEM designation (see above) of sender. 

2. SYSTEM or SUBSYSTEM designation (see above) of sender. 

3. PROCESS designation (see above) of sender. 

1* .SUPER-SYSTEM, designation (see above) of receiver. 

2'. SYSTEM or SUBSYSTEM designation (see above) of receiver. 
3'. PROCESS dsi gnat ion Csee above) of receiver. 



V. PROCESSING RULES 

Processing rules are numbered serially within 
processes and are recorded on Form B-7 



model AA /AAA /nFTF? :• 

e.g. AQ.ORD. 007 

1. SYSTEM OR SUBSYSTEM 

2. PROCESS 

3. RULE NUMBER 

BEFORE ACCEPTANCE/ ALL PROPOSED MNEMONICS MUST BE 
TESTED FOR UNIQUENESS AGAINST THE CUMULATIVE 
MASTER LISTS,, AND APPROVED BY PROJECT DOCUMENTATION. 



SPIRES/BALLOTS PROJECT 
DOCUMENTATION STANDARD DS.114 


Section 


Pfi ; r ,n 


Date shJx/70 N ( /O R ( 'J 


riTLF: SYSTEM FLOWCHARTS — SYMBOLS AND CONVENTIONS 



1.1 System Flowcharts 



SYSTEM FLOWCHARTS show the flow of data through a processing system. 

In a library this is the flow of bibliographic and related data through 
library systems/ such as acquisition and through processes/ such as 
ordering. In general a system flowchart consists of : 

ACTIVITY SYMBOLS — standard shapes which Indicate a general type 

of activity. 

ACTIVITY DES I GNAT I ONS— a . phrase or name convention which describes 

activity at a point in the data flow. 

MEDIA SYMBOLS--standard shapes which indicate a data storage or 
transmission medium (e.g. input or output). 

FLOW L INEJS/CONNECTORS-* *1 i nks between symbols which indicate the 

type(manual or automated) and direction of 
flow. 

COMMENTS/NOTES— wr i tten statements which are not part of the data 

flow,. but say something about it. 

1.2 Chart Levels j 

Two levels of system flowcharts are prepared. LEVEL 1 charts and 
LEVEL I 1 charts. j 

LEVEL I. Level I charts are prepared for each current system and each 
proposed system. Level I charts are presented to library management 
and must be understandable to and understood by all library managers. 

i 

Level 1 charts include major processes, ? nputs/outputs, files and 
documents. These are named and numbered according to DS.113 "Naming/ 
Numbering Conventions" on the proposed system charts only. Both 
manual and automated processes are shown on the proposed system charts. 
Manual processes shown are those affected by automation. 

LEVEL il. Level il charts are prepared for the proposed systems only. ! 
They are for Department and Division Heads. Each unit manager must 
understand all the details of ;the charts covering his/her area. 

I j 

Level li charts must show all ;inputs and outputs, all files, search j 
requests, and terminal displays (CRT or typewr i ter) .All inputs, output; 
processes, procedures and files are systematically and uniquely named 
and numbered, (see DS.113 "Naming/Numbering Conventions".) . i 
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jj 1.3 Rules for Preparation _ 

vj PAPER. Charts are prepared on 17"x22" paper and photo red ced to 
“n 8-l/2"xll". 

MARGINS. The first (i.e left-most) sheet has a 2" left margin and 1" on 
three sides. Continuation sheets on foldout charts are drawn 
j I t with 1" margins all around. 

SYMBOLS. The following symbols are standard on all system flowcharts, 
jj Standard forms ( shapes ) of symbols are used but not a standard 

'' size. Verbal contents of symbols are typed on sheets of self- 

adhesive label paper and then symbols are drawn around the 
jj typewritten information. 

FLOW. System flow is always left to right and incoming flow may be 
i ; shown top to bottom. 

(i 

i.D. BLOCK. An Identification block must be completed for each chart 
, and placed In the lower right hand corner of the chart, 

j It contains three parts: 



I) 



D 
L! 

II 

SYMBOL 

0 



REVISION SECTION. The first chart is called "Initial Version" and "0" 

is placed in: the "Rev" box. Subsequent revisions are 
• l...n and a brief explanation of added or changed 
material is placed in the "remarks" box. The person 
responsible for the chart or change supplies his/her 
ini t i a 1 s . 

ID. The system and subsystem is identified using the standard naming 
conventions found in DS. 113. 

TITLE. This is a prose statement of the naming code found in the ID. 

Current or Proposed system must be stated in the title and also 

the chart level. Here Is an example of $n ID and TITLE, 

ID:' B.AQ.ORD 

TITLE: CURRENT ACQUISITION SUBSYSTEM / ORDER PROCESS 
LEVEL II 



1.3 Flowchart Symbols and Interpretations 

INTERPRETATION 

1.3.1 Designating System Activity 



EXAMPLE 



j i D b 



j. A CT W»T^/ 
lpc^c«\.v?rioN } 



q} 

I.ERJC 



Each rectangular system activity symbol has 
three parts / a SYSTEM LEVEL NAME, a SYSTEM 
LEVEL ID, and an ACTIVITY DESCRIPTION. 

A level name is one or more of the follow- 
ing elements in the order indicated: System/ 
Subsystem/Process/Procedure/Step. A level ID 
follows the the naming/numbering system in 
DS.113, e.g. CR.ICI— a process in the circu- 
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SYMBOL INTERPRETATION EXAMPLE 



lation system. An activity description names 
the specific activity, e.g. "Initial Check-In". 

1.3.2 Types of System Activity Symbols 

AUTOMATED 

Indicates completely automated system 
activity. There Is no manual Intervention 
at this level or or at lower levels, 

(e.g. lower level procedures or operations). 



CP. % i 

~P. IPO 

V=lUL ypo/pTE- 



PART I ALLY AUTOMATED 

System activity which is composed of both 
automated and manual activitie , at this 
or lower system levels. 



ftp, ore-p 



MANUAL ONLY 

System activity which Is composed of 
completely manual activities at this or 
lower system levels. 



PP.OC.E.DU R.fe_ 
IT. P^.Ql 

I'lAraR.lA.u 
OlVTru eviTi^u 



1ANUAL, AFFECTED BY AUTOMATION 
lanual system activity in the 
ibrary system which will 
lutomation in the 



current 
be affected 
proposed system. 



by 



1.3.3 Media Symbols (Input/output, storage) 
TERMINAL ! 

Indicates date Input or output at a type- 
writer terminal or at a machine-readable 
book ID reading station. Each input or . 
output is given a unique ID. 

FORMS: input, B-4, 8-9 . , ; 

output B-5 . 




CRT(Cathode Ray Tube) DISPLAY 
Indicates data input or output on a 
visual display device. Each input or 
output is given a unique ID. 

FORMS: input, B-4, B-9 
output, B-5 

ON-LINE DISK FILE 

Indicates an on-line disk file. Each 

file is given a uniques ID and descriptive 

name. 

FORMS: B-6, B-10 ■ . 
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SYMBOL INTERPRETATION EXAMPLE 



MAGNETIC TAPE FILE 

Inoicates a magnetic tape file, either 
on-line or off-line. Each file is given 
a unique ID and descriptive namd. 

FORMS: input, B-4, B-9; output, 8-5 
Internal storage, B-6, B-10. 

INTERNAL RECORD 

A machine-readable record Internal to an 
automated process as distinct from a 
Document(see below) or other hard copy 
representation of a record, 

FORMS: B-6, B-10 




/Aa t .QM>.iu ojj 

/1M Pn.oc.aiA 
Fils 
I VP OATE. 



PUNCHED CARD 

Indicates a punched card either as input 


OSOX 


Sfi.AO.CUr 


output or storage. 


Call 


FORMS: input, B-4, B-9 


iu\ p 



-n 



w/e OTPv/T ID 



CffiscOPTiC) 



LIBRARY MATERIAL (Machine- readable) 
Indicates library material such as a 
book or periodical with a machine- 
readable ID. 

FORMS: input, B-4, B-9 
output, B-5 



LT.K'z'/. 

IfcOOK. WVTU 





LIBRARY MATERIAL (Not machine-readable) 






Indicates library material 


such as a 






book or periodical without 


a machine- *. 


t2c*»K» 




readable ID. 


V 




which is 
activity or 
automated 



DOCUMENT 

Indicates either a manual form 
INPUT to a partially automated 
a REPORT which is OUTPUT by an 
system act i vi ty . 

FORMS: input, B-4, B-9 
output, B-5 



MANUAL FILE 

A manual file of documents or records, 
A file description Is indicated In a 
dotted box next to the symbol. 




‘CFu-e- 



j OeAC«.»«*-noa^j 
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SYMBOL INTERPRETATION EXAMPLE 




1.3.4 Flow Lines and Connectors 

System flow is always from left to right 
across the page. 

DATA FLOW 

Indicates automated data flow 



-> 



; . y Indicates manual data flow 

) 



> 









) 



SOURCE/DESTINATION FLOW 

v Indicates input source flowing Into a 
system or subsystem. 



< ( output* 'N 

OasTl UKTiouV 



Indicates output destination flowing 
out of a system or subsystem. 



CONNECTORS 







} 







Connectors indicate entry from or exit 
to another part of the flowchart. 




5 




Entry Connector 
Exi t Connector 





■> 




1.3.5 Comments and Notes 

DOTTED BOX ~j 

Indicates explanation or additional , /w-prt/v-<ie.v { 

commment on the system flow. « Vamtsa a i*\— j 




if 

! 

f- 

I 



CO feS^ m i pTt 




DOTTED LINE 

Indicates a direction description. That 
is, some kind of decisions has been made 
in the preceding system ativity and this 
describes one or more flows out of that 
activity. 
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Section 
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New ( ) Rev (>C 


Date 6/10/70 


TITLE: NAME LISTS — SYSTEM, SUBSYSTEM, PROCESS, FILES 
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INTRODUCTION 



purposes library processing is conceptualized at six 
e are called: System, Subsystem, Process, Procedure, 



For analysis 

levels* T h e ;> e ■ ■ — -- — , - - — - 

Operation and. Step. The total library process organization 
is considered a Supersystem. During Phase B, analysis focuses 
primarily on activities at the level of procedures and above. 



Each process, file. Input/output, and interface must be uniquely 
named for identification purposes. This Is done using the naming/ 
conventions found in DS.113. The following list is the 
applying these conventions. Additions or changes to 
are made by the Documentation Office. A revised list 
periodically. An alphabetical list (index) to all 
is found as the last list in this standard. 



numbe r i ng 
result of 
this list 
i s i ssued 
mnemon i cs 



SUPER-SYSTEM NAMES 



BALLOTS 

SPIRES 



B 

S 



SYSTEM and SUBSYSTEM NAMES 



jbRJt 



Accounting Subsystem 




.AC 


B.AC 


Acquisition Subsystem 




.AQ 


B. AQ 


Binding and Finishing Subsystem 


.BF 


B. BF 


Cataloging Subsystem 




.CT 


B.CT 


Circulation System 




.CR 


B.CR 


Reserve Processing System 




.RP 


B.RP 


Technical Processing System 




.TP 


. B .TP 


:0CESS NAMES 


Abel Approval Payment (Voucher Prep) 


.ABL 


B.AC. ABL 


Abel "D" Order Payment (Bill 


Prep) • 


. DBP 


B.AC. DBP 


Bindery Outgoing ; 




.BOG 


B.BF. BOG 


Bindery Receiving 




.BRE 


B. BF . BRE 


Book Invoice Payment 




. B 1 P 


B.AC.B1 P 


Cancellation 




.CAM 


B . AQ. CAM 


Circulation Print 




. PRT 


B.CR. PRT 


Circulation Search 




. CSH 


B.CR. CSH 


Circulation Search Cycle i 




.SHC 


B.CR. SHC 


Charging 




. CRG 


B.CR. CRG 


"D" Order Voucher Preparation 


. DVP 


B.AC. DVP 


Del i nquent 




.DLQ 


B.CR. DLQ 


Discharging 




.DIS 


B.CR.DI S 


Fine Payment 




. FPT 


B.CR. FPT 


End Processing 




.END 


B.BF. END 


Fine Search 




. FSH 


B.CR. FSH 
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3 



r'N 

'J 



Hoi d/Recal 1 


.HLD 


. B.CR.HLD 


In Process File Update 


. 1 PU 


B.TP. 1 PU 


Ini t ial Check- 1 n 


. ICI 


B.CR. ICI 


Lost Book Bill Identification 


.BID 


B.CR.BI D 


Lost Book Bill Update 


.BUD 


B.CR. BUD 


Manual Cancellation 


.MCN 


B.AQ.MCN 


Manual Exchange Request Processing 


.EXC 


B.AQ.EXC 


Manual Material Claiming t 


.MMC 


B.AQ.MMC 


Manual Material Receipt 


.MMR 


B.AQ.MMR 


Manual OP Procurement 


.MOP 


B.AQ.MOP 


Manual Ordering 


.MOR 


B.AQ.MOR 


Manual PL 480 Material Receipt 


. PLR 


B. AO.. PLR 


MARC’ Data Extraction 


.MRC 


B.TP. MRC 


MARC Processing 


.MAR 


B.TP. MAR 


Material Claiming 


.MCL 


B. AO. MCL 


Meyer Data Extraction 


.MEY 


B.TP. MEY 


Missing ' 


.MIS 


B.CR. Ml S 


Non Purchase Order Material Receipt 


. NPO 


B.AQ.NPO 


Off Reserve 


. OFR 


B.RP.OFR 


Order i ng • , 


.ORD 


B.AQ.ORD 


Output Pr i nt i.ng 


.OPP 


B.TP. OPP 


Overdue 


.OVD 


B.CR. OVD 


Patron Search 


.PSH 


B.CR. PSH 


P.0. Material Receipt 


.POR 


B.AQ.POR 


Problem Processing 


. PRO 


B.AQ.PRO 


Repair 


.REP 


B.BF.REP 


Report Processing 


.ST A 


B.AQ.STA 


Reserve Book Listing 


. RBL 


B.RP.RBL 


Reserve Book Processing 


. RBP 


B.RP.RBP 


Reserve Ordering 


. ROD 


B.RP.ROD 


Reserve Printing 


. RPT ■ 


B.RP.RPT 


Reserve Search 


. RSH 


B.RP.RSH 


Selection 


.SEL 


B.AQ.SEL 


Serial Check In 


.SCI 


B.AQ.SCI 


Serial Payment and Credit Notation 


.SER 


B. AC. SER 


Shelf Search 


. SSH 


B.CR. SSH 


Voucher Check and Completion 


. BVC 


.B. AC. BVC 



FILE NAMES 

Fine File 
Statistics File 
In Process File 
I nventory File 
MARC File 

Name and Address File 



O 

ERIC- 



FIN 


BCRF1N 


STS 


BCRSTS 


IPF 


BTPI PF 


1 MV 


BCR 1 NV 


MRC 


BTPMRC 


NAM 


BCRNAM 


. . . 



183 



SPIRES/BALLOTS PROJECT 
DOCUMENTATION STANDARD DS.116 ’ 


Section 


Page 5 of 4 


Nov/ ( ) Rev ( ) 


Date r/ 10/7 0 


TITLE: NAME L 1 STS--SYSTEM, SUBSYSTEM, PROCESS, FILES 



ALPHABETICAL LIST OF MNEMONICS 



B 

B. AC 

f , B.AC.ABL 
B.AC.BI P 
B.AC.BVC 
B.AC.DBP 
B.AC.DVP 
B. AC. SER 
B.AQ 

B.AQ. CAN 
B.AQ.EXC 
B.AQ.MCN 
B.AQ.MMC 
B.AQ.MMR 
B.AQ. MOP 
B. AQ.MOR 
B.AQ.MCL 
B.AQ. N PO 
B. AQ.ORD 
B.AQ.PLR 
B.AQ. POR 

A. AQ.PRO 

B. AQ. SCI 

A. AQ.SEL 

B. AQ. STA 
B.BF 

B.BF.BOG 
B.BF. BRE 
B.BF. END 
B.BF. REP 
'• B.CR 
B.CR.BID 
B.CR. BUD 
B.CR.CRG 
' B.CR.CSH 
B.CR.DI S 
B.CR.DLQ 
• BCRFIN 
B.CR.FPT 



B.CR.FSH 
B.CR. HID 
B.CR. ICI 
BCR I NV 
B.CR. MIS 



BCR MAM 
B.CR. OVD 
B.CR.PRT 
rn ?JR.PSH 

M:KJC 



BALLOTS 

Accounting Sybsystem 

Abel Approval Payment (Voucher Prep) 

Book Invoice Payment 

Voucher Check and Completion 

Abel "D" Order Payment (Bill Prep) 

"D" Order Voucher Preparation 
Serial Payment and* Credit Notation 
Acquisition Subsystem 
Cancellation Process 

Manual Exchange Request Processing Process 

Manual Cancellation Process 

Manual Material Claiming Process 

Manual Material Receipt 

Manual OP Procurement Process 

Manual Ordering 

Material Claiming Process 

Non Purchase Order Material' Receipt Process 
0 rderi ng Process 

Manual PL 480 Material Receipt Process 
P.0. Material Receipt Process' 

Problem Processing Process 

Serial Check In 

Selection Process 

Report Processing Process 

Binding and Finishing Subsystem 

Bindery Outgoing 

Bindery Receiving 

End Processing 

Repair 

Circulation System 

Lost Book Bill Identification Process 

Lost Book Bill Update Process 

Charging Process 

Circulation Search Process 

Discharging Process 

Delinouent Processing 

Fine File 

Fine Payment Process . .. 

Fine Search Process 

Hold/Recall Process 

Initial Check-In Process 

Inventory File 

Missing Process 

Name and Address File 

Overdue Process 

Circulation Print Process 

Patron Search 



1.67 
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flTLE: 



SPIRES/BALLOTS PROJECT 

DOCUMENTATION STANDARD DS. 116 



NAME 1. 1 STS--SYSTEM, SUBSYSTEM, PROCESS, 



See Li on 
Pntje 4 of 4 



New ( ) 



Rev ( ) 



Date 6/ 10/ 7 0 



F I LES 



B.CR.SHC 
B.CR.SSH 
B. CR. STS 
B.CT 
B.RP 

B.RP.OFR 

B.RP.RBL 

B.RP.RBP 

B.RP. ROD 

B.RP.RPT 

B.RP.RSH 

B.TP 

BTPIPF 

B.TP. I PU 

B.TP. MAR 

B.TP.MEY 

BTPMRC 

B.TP.MRC 

B.TP.OPP 

S 



o 

ERIC 



Circulation Search Cycle Process 
Shelf Search Process 
Statistics File 
Cataloging Subsystem 
Reserve Processing System 
Off Reserve Process 
Reserve Book Listing Process 
Reserve Book Processing Process 
Reserve Ordering Process 
Reserve Printing Process 
Reserve Search Process 
Technical Processing System 
In Proccss^File 

In Process File Update Process 
MARC Processing Process 
Meyer Data Extraction Process 
MARC File 

MARC Data Extraction Process 
Output Printing Process 
SPIRES 
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ASSUMPTION/ CONCEPT 
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The following files will be accessible for on-line sea 
period: Sam.-5pro., Mon.-Fri.: (1) Acquisition In Pi 

(2) MARC File and/or 

(3) Serial Payment Fi 

Files can be updated down through the data element le\ 
elements can be selectively maintained e.g., if one ac 
is changed, out of three present, the values of the ol 
be re-entered. 

Data reflecting acquisition activities for separate cc 
monograph (independent ordering schedules) will be he 
necessary bibliographic data in one record within the 
File . Each of these records will carry an unique idei: 
ID3217. Activity data covering a particular copy will 
bibliographic data by suffixing the identification nus 
lly assigned pointer (YY) in the form IDXXXXXX.YY wher 
example, if there is an In Process File record numbere 
.graphic data only could be retrieved on-line by using 
graphic data and activity data on a copy order 3/1/70 
Library through use of ID3217.1; similarly, data on tb 
3/4/70 by ID3217.2, and the copy for the Chemistry Dej 
through ID3217.3. 
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date: 4/14 /Ij 






S and CONCEPTS 



_A yjTIIOR J JEAJL 

system: technical 



A 
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PROCESS INC- ACQUI S ITIONji 



1 m ••.vw.Wiio.T u r.ii t.V.s, *! 



ASSUMPTION/ CONCEPT 



SOURCE 



Utwwwwiw * n WW '.W W 



ill be accessible for on-line searching during the time 
on.-Fri.: (1) Acquisition In Process File 

(2) MARC File and/or MARC Index Files 

(3) Serial Payment File 

down through the data element level. Multiple data 
tively maintained e.g., if one added personal name entry 
ree present, the values of the other two do not have to 

sition activities for separate copies of the same 
nt ordering schedules) will be held together with the 
ic data in one record within the Acquisition In Process 
records will carry an unique identification number e.g., 
a covering a particular copy will be accessible with the 
suffixing the identification number with a chronoiogica- 
(YY) in the form IDXXXXXX.YY where YY = l,2,...,n. For 
an In Process File record numbered ID3217, the biblio- 
Id be retrieved on-line by using ID3217, the biblio- 
vity data on a copy order 3/1/70 for the Engineering 
f ID3217.1; similarly, data on the approval copy received 
nd the copy for the Chemistry Department ordered 3/10/70 
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ASSUMPTION/ CONCEPT 



8 



File security will be provided to prevent unauthorized 
retrieval. 

Unsuccessful MARC requests will be accumulated and re-j 
subsequently received for a specificed time period. 

Data entering the Acquisition Subsystem will, be edited 
individually and in context. 

Performance statistics on system operation down througl 
be provided on management reports 

Status alerting service will be provided for: (1) claii 
(2) serial invoices, and (3) invoice line item matching 
tion. 

At completion of technical processing, the In Process j 
transferred to a historical file. i 
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SYSTEM*. TECHNICAL PROC 
(ACQUISITION) 
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ASSUMPTION/ CONCEPT 



TECHNICAL PROCi 
JISITION)^; I 

n 



[source 
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ill be provided to prevent unauthorized record maintenance or 1 BALLOTS I 

• EAM 

RC requests will be accumulated and re-passed against MARC Files BALLOTS I 



ceived for a specificed time period. 

:he Acquisition Subsystem will, be edited for validity 
;d in context. 

ftistics on system operation down through the process level will 
management reports 

service will be provided for: (1) claims (material and invoice, 
ices, and (3) invoice line item matching and voucher prepara- 

f technical processing, the In Process- File record will be 
a historical file. 



f EAM 

BALLOTS . I 
EAM- 

BALLOTS I 
EAM 
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{•'. ! system: technical proc}'autiior: eam 


"1 
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SUBSYSTEM: ACQUISITION ?DATE: 4/13/70 




^ MANAGEMENT DECISIC 



\ 



£ ■ 

:PRIO 

.11 TY 
1 



2 



'IMPORT. 

AFTER 

DEC. 




la 



How will MARC data be stored and used? 
Will both 'the MARC File and its 
supporting indexes be on-line? 



1) No MARC 

2) MARC + INDEXES on-lj 

3) Indexes only on-lin 

etc. . . 



Will MARC File records be converted to 
the BALLOTS input format before or 
after selection? . . : . . _ . 



3 



An additional list of management 
decisions will be prepared and reported 
4/10/70 in a carry-over study covering 
the basic acquisition system. Decision:; 
will be requested on: support for 

exchange, cost accounting, fund balance 
files, and SDI lists. 



4 



Can the interface medium with Accounts 
Payable be changed from printed vouchers 
to magnetic tape? 



1) we print voucher 

2) we produce magnetic, 

output.....^.... 
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ored and used? 1) 
and its 2) 
t-line? 3) 

)e converted to 
: before or 



nagement ' 

;ed and reported 
study covering 
rstem. Decisions 
support for 
ig, fund balance 



i with Accounts 1) 
printed voucher«2) 
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A MANAGEMENT DECISIONS * 
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ALTERNATIVES 


[dec. DEADLINE 
“(EVENT/ DATE) 


EFFECT OF 1 
FAILURE T( 
DECIDE 


No MARC 

MARC + INDEXES on-line 
Indexes only on-line, 
etc. ... 


BEFORE END 
of Period I] 
by 5/1 
preferably . 


No MARC t 
use 




By 5/1 
* 


No MARC 


• - ' ■■ ••• ~ •••• ■ • 


Report on 
Scope by 
4/17 


■ 


• 


Decisions b-> 
4/24 


• 


we print voucher 

we produce magnetic tape 

output. 


5/1 


! 

< 

We print | 
voucher ! 


. • ■ • ■. -* ■ - - i-- •• > • 
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The following files will be accessible for on-line searching du 
period: Sam-5pm, Mon.-Fri.: (1) , Cataloging In Process File 

(2) MARC File and/or MARC Index 

All machine readable bibliographic data will be captured after 
technical processing, (i.e., full bibliographic data in machine 
will be saved in some form) 

National and Stanford-created bibliographic data wi? be used 1 
cards in filing order for the Catalog Department (s~ope of proc 
decided) . 

Spine labels and machine readable book circulation identif icati 
created from Cataloging In Process File data. 

Cataloging will be deferred on material where appropriate, for 
time, in order to chance arrival of MARC bibliographic data. 
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How will MARC data be stored and used? 
Will both' the MARC File and its 
supporting indexes be on-line? 

Till MARC File records be converted to 
the BALLOTS input format before or 
after selection? . 

An additional list of management dec- 
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4/10/70 in a carry-over study covering 
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That will be the disposition of 
machine readable bibliographic data? 
Till it be used to build an on-line 
catalog file or saved on : a listing 
file. In .the latter use, how would 
updating be accomplished? 
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The processes: * Charging, Discharging, Fine Payment 
be on-line. 

Machine readable book and patron identification wil 

[ Charging will be performed by the. patron (self-serv 

The Circulation System will be based on an Inventor 
and on a Circulation File at the Main Library. 

. . ft . 

| There will be a file of all eligible patrons, based 
| Administrative Data Processing. 

| Discharging will be done from the book not from a s. 
j Communication between the MARC, IPF, Inventory, and 
l On-line update of all disk files. 
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6.5 Data Preparation and Data Control 
(referred to in subsection 2.9.2, 

2. 10.3, 2.10.4, and 2. 10.5) 

1. Data Preparation Procedures and Forms 
Manual 

2. Build Program Error Diagnostics 

3. Automatic Job Control Language Generator 
k. Vendor Address File Procedure 

5. Record Update, Claim, and Cancellation Forms 

6. Universal Bibliographic Data Form 
7 • Search Guide 




DATA PREPARATION PROCEDURES AND FORMS MANUAL 



The following standards for procedures and forms were 
established during operations of the Data Preparation Depart 
ment/ when It was servicing the prototype Acquisition System 
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Simple Pre-Coding for Order Department Searchers 216 

Coding of Author(s) in Acquisition Information without 
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COD l MG OF ACQUISITION REQUEST AND BIBLIOGRAPHIC DATA 
DESCRIPTION: 



The Acquisition Division receives requests for the purchase 
of books on SUL-25 request cards. (If the request comes in any 
other form/ the searchers type the request onto an SUL-25 card 
themselves.) The back of the request card contains space for 
writing searching information. After the request is searched/ 
the typist in the Acquisition Division uses the request card as 
the source of information from which to type a purchase order. 
Science approval material arrives with dealer-prepared process 
slips. In preparation for computer input/ the information on the 
request card or process slip and on the LC card or proof slip is 
tagged with BALLOTS data element mnemonics. The initial process 
by which the information is prepared for computer input is called 
coding--acquisi tion and bibliographic coding. 

Responsibility Steps 



1. Asst. Chief Biblio- 1. Selects the requests/ searched the 

grapher/ Acquisition day before/ to be assigned a BALLOTS 

Division ID number. Gives them to Acquisition 

Division Secretary. 



2. Acquisition Division 
Secretary 



3. Acquisition Division 
Secretary 



4. Data Preparation 
Coder 



5. Data Preparation 
Coder 



6. Data Preparation 
Coder 



2. Assigns a BALLOTS ID number/ taken 
from the Check Digit Print-out/ to 
each request (or approval process 
slip). With red ink/ she writes the 
ID number in the upper left hand 
corner of each request. 

3. Xeroxes requests, as well as any 
attached LC cards or proof slips, onto 
Input Coding Sheet form. Places 
BALLOTS Input Coding Sheets into 
BALLOTS Bibliographic Pick-Up box in 
the Order Department. 

4. At approximately 9:00 a.m.. Data 
Preparation Coder picks up the BALLOTS 
Input Coding Sheets and takes them 

to Data Preparation Office (Rm. 335). 

5. Coding Sheets are sorted into two 
categories-- those with an LC card 
(or proof sHp) and those wi thout an 
LC cardl 

6. The coder analyzes each request and, 
using the mnemonic codes from the 
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. Data Element List and a red pencil, 
tags each element of information 
according to BALLOTS regulations. 
(See Append ix A.) 


Coder 

1 

( 

/ 


7. 


As each category is coded, the coder 
keeps statistics (using the Daily 
Processing Statistics Form) on the 
number of sheets coded and the amoun 
of time taken to code each category. 


Coder 


8. 


As each coding sheet is completed, 
the coder writes her initials and th 
date in the lower right hand corner 
box. 


Coder 


9. 


When all the coding sheets are 
completed, they are given to the 
editor (Data Preparation Supervisor) 



Equipment used: a. Xerox machine 

Forms used: a. Check Digit Print-OUt 

b. BALLOTS Input Coding Sheet 

c. Data Element List 

d. Bibliographic Coding Procedures - Appendix A 

e. Daily Processing Statistics Form 
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6. Editor (Data 6. When all Input coding sheets are 

Preparation ready for input/ the editor delivers 

Supervisor) them to Data Control before 5:00 p.m. 

Department: Data Preparation 

Equipment used: None 

Forms used: a. BALLOTS Input Coding Sheet 

b. Data Element List 

c. Bibliographic Coding Procedures. 




EDITING OF ACQUISITION AND BIBLIOGRAPHIC CODING 
DESCRIPTION: 



It is important 
be accurately coded, 
their own work since 
Therefore, it is the 


that the information in the In Process File 
Coders cannot be expected to proofread 
they are prone to overlook their own errors, 
responsibility of the editor (Data 



Preparation Supervisor) to edit the input coding sheets. 



Respons l bl i ty 


Steps 


1. Editor (Data 
Preparation 
Supervisor) 


1. Receives coding sheets from the coder 
for editing. 


2, Editor (Data 
Preparation 
Superv i sor ) 


2. Divides the coding sheets into two 

categories (as was done by the coder) 
--with LC cards (or proof slips) 
and without LC card. 


3. Editor (Data 
Preparat 1 on 
Supervisor) 


3. Using the Data Element List, care- 
fully proofreads and checks to see 
that all coding is correct. Errors 
are indicated with a green pencil. 


4. Editor (Data 
Preparat ion 
Supervisor) 


.4. As each coding sheet is edited, the 
editor writes her initials and the 
date in the lower right hand corner 
box. This is the final approval and 
the editor's initials signify that 
the coding sheet is ready for input. 


5. Editor (Data 
Preparation 
Supervisor) 


5. As the proofreading and editing of 
each category are completed, the 
editor keeps statistics of the number 
of coding sheets and the amount of 
' time taken to edit each group on the 
. Dally Processing Statistics Form. 



UPDATE PROCESSING 



Description: 

If an update is required to a record in the In Process File, 
the Department generating the Update (Acquisition or Catalog) 
prepares an Acquisition Catalog Update Report (A/C Update 
Report), a Cancellation Information Sheet (Cancellation Sheet), 
or a Claiming Information Sheet (Claim Sheet), depending on the 
type of update. These forms are collected and reviewed daily by 
Data Preparation before going to Data Control. (Note:- "Update 
Sheets" is the term used to include all three types above.) 



Respons f b J H ty 


Steps 


Daily 

1. Data Preparation 
Supervisor 


1. Picks up all Update Sheets each 
morning from designated boxes in 
the Catalog and Acquisition 
Departments . 


2. Data Preparation 
Supervi sor 


2. Counts the number of Update Sheets 
received from the Catalog Department 
and records this number on the Update 
Statistics Sheet. 


3. Data Preparation 
Supervisor 


3. Counts the exact number of Update 

Sheets received from the Acquisition 
Department and records this number on 
the Update Statistics Sheet. 


4. Data Preparation 
Supervi sor 

v ■ ; 


4. Records the number of Cancellation 
and Claim Sheets received on the 
Update Statistics Sheets. 


5. Data Preparation 
Supervisor 


5. Figures the total number of Update 
Sheets (by adding numbers from 
Acquisition and Cataloging) and 
records this number on the Update 


< 


Statistics Sheets. 


6. Data Preparation 
Supervisor 


6. Checks the A/C Update Reports to be 

sure each has an identification number 
and to see that the action requested 
on each sheet is clear. , 


' 4 r 


. /- . . 

a. If the desired action is not 
clear, goes to the person whose 
initials are written at the bottom 
and finds out exactly what action 
was Intended. 


eric: . 






0 

[I 



0 

0 

0 

0 



0 

0 



7 Data Preparation 
Supervi sor 



Corrects or clarifies the A/C Update 
Report. 

7. Looks over the Cancellation and Clain 
Sheets In the same manner, with one 
additional checkpo i nt-- the vendor 
identification number. 



8. Data Preparation 
Superv i sor 

Weekly 

1. Data Preparation 
Superv i sor 

Month 1 y 

1. Data Preparation 
Supervi sor 

Equipment used: None 



8. Gives all Update Sheets to the Data 
Control Supervisor immediately. 



1. Figures the weekly totals on the 
Update Statistics Sheet. 



1. Figures the monthly totals on the 
Update Statistics Sheet. 



Forms used: a. Acquisition/Catalog Update Report 

b. Cancellation Information Sheet 

c. Claiming Information Sheet 

d. Update Statistics Sheet 
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BALLOTS INPUT CODING SHEET 



Purpose: 

The BALLOTS Input Coding Sheet is the medium for 
transmitting acquisition and bibliographic information to Data 
Preparation in such a way as to facilitate the classification and 
tagging (coding) of the data with BALLOTS data element mnemonics. 
Data Control receives the completed Input Coding Sheet as the 
source document for computer input (using WYLBUR) and 
proofread i ng. 



Use by Data Preparation 



l.« The layout of the Input Codi 
data by type: SUL-25 Request (A 

(Area C); Bibliographic Descript 
E). Consequently its use is det 
Following is a sample of a blank 
card is xeroxed onto Area A; if 
proofslip) is xeroxed onto Area 

a. SUL-25 Data: The acquis 

information if no LC Card is 
preprinted mnemonics. A red 
mnemonics to the first chara 



ng Sheet explicitly categorizes 
rea A); LC Card (Area B); Control 
ion (Area D); and foldings (Area 
ermined by stringent rules. 

coding sheet. The SUL-25 Request 
available the LC card (or 
B. j, 

5 

ition data (and bibliographic 
present) is codedjusing the 
line is drawn frorji the printed 
cter of the data. I 



b. LC Data: The bibliographic information onj LC cards is 

not consistently present and therefore the mne|nonics must 
be supplied by the coder. The blank spaces orj both sides 
of Area B are provided for this purpose. Limls are drawn 
directly from the mnemonics to the first character of the 
data. 

c. Control Data: The first column on the lrff.t containing 

preprinted mnemonic tags is used to code acquisition control 
information such as what notices are needed p r what is 
ordered. Only pertinent information is supplied. 

I 

ci. Bibliographic description data: The second column on 

the left containing preprinted mnemonic tags is used to 
explicitly code information which is Implicit on the LC 
card such as language of the text and country of publication. 
^ These data are supplied only when an LC card is present. 

e. Holdings Data: Coders supply holdings data for Abel 

approval material only. 

Use by Data Control [ 
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1. The Input Coding Sheet is used as the source document for 
Input of acqui s i tion and bibl iographic data. 

a. The layout of the form allows the terminal operator to 
easily follow the flow of mnemon i cs---f rom left to right and 
down each column. The lines drawn from the tag to the data 
Indicate exactly what to type after each mnemonic. 

2. The Input Coding Sheet is also used as the sourcel document to 
proofread the data after it has been input and listed at the 
terml nal . 

3. The Coding Sheet is filed in ID number sequence for future 
reference. 



Purpose : 



UPDATE STATISTICS SHEET 



To count the number of updates received dally from the 
Catalog and Acquisition Divisions and to figure the weekly and 
month 1 y total s . 

Use by Data Preparation 

1. Update sheets are divided into 4 categories: catalog, 

acquisitions, cancellations, claims. The Data Preparation 
Supervisor records the number of update sheets by category daily 
and calculates the total. 

2. Summary totals are calculated weekly and monthly. 

3. Summary statistics form the basis of the Supervisors monthly 
report to the Data Preparation/Control Coordinator. 
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Pur pose 
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DAILY PROCESSING STATISTICS 



To record the number of coding sheets received dally and the 
amount of time taken to code and to edit the coding sheets. The 
sheets are divided into two categor i es--those wi th an LC card and 
those without an LC card; and the amount of time taken to code 
each category is computed separately. 

Use by Data Preparation 

1. On Monday, the dates for the week and the function--codi ng or 
ed i t 1 ng--must be written at the top of the sheet. 

2. Each day, the number of items for each category (no LC Card-- 
English; with LC card — English; with LC card — non-English; and no 
LC Card--non-Engl ish) is counted and written in the appropriate 
box (see following sample), 

3, The coder (or editor) must write the starting time and ending 
time for each category as each is done, 

4, When all coding sheets are completed, she will fill in the 
Total Minutes and initial (since different people are responsible 
for coding on different days). 
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MONTHLY PROCESSING SUMMARY STATISTICS. 



Purpose : 

To summarize on one sheet the statistics from the Daily 
Processing Statistics Sheet# and to figure the average minutes 
per l tern needed to process a. coding sheet. 

, ( 

Use by Data Preparation 

l , 

■ 1. Statistics are kept on this form in the same way for coding 
and editing in the Data Preparation Department as they are for 
inputting and proofing in the Data Control Department. 

Therefore# the department and function must always be written 
In the upper right-hand corner. 

2. Coding sheets with an L.C card (or proof slip) and coding 
sheets without an LC card (or proof s 1 i p) are tallied separately. 

3. The figures are transferred from the Daily Processing 
Statistics Sheet once a month. The totals are then calculated so 
that the Total Time can be divided by the No. of I terns in order to 
derive the Average Minutes per I tern (see following sample). 

4. There Is room for two months' worth of statistics on one form. 
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A ACQUISITION AND BIBLIOGRAPHIC CODING PROCEDURES 
Introduction 

Use this guide as a supplement to the Data Element list. The 
guide is geared to the coding sheet and is divided into two 
segments. D art A discusses the Acquisition Control and 
bibliographic data to be tagged on the Input Coding Sheet. 

Control data elements apply to all material. Bibliographic data 
on the SUL-25 request slip or dealer-supplied process slip is 
coded if an LC Card was not found during Acquisition searching. 

If an LC Card or proofslip is found and xeroxed onto the coding 
sheet/ bibl iograph ic data is coded from that. LC bibliographic 
coding is covered in Part B. 



A. Acquisition Control and Bibliographic Data 



1. PRO - The most common types of procurement are: regular 

purchase order (po)/ approval (a)/ and standing order (s). 

There are, however, other- .poss i b i 1 i ties listed in the Data 
Element List. An approval book is easily recognized by its 
distinct form - the coding sheet contains a dealer-supplied 
process slip rather than a SUL-25 request or proof slip. All 
other requests will have a note written on them saying what 
type of procurement is desired; for example, "Standing order 
to begin with vol. 1 and to continue," or the word 
"prepayment" may follow the price. If there is no 

clue given on a request as to the type of procurement, 
then I t is a regular purchase order. , 

2. XOR - Not currently used. 

3. PRI - A priority Item will have the words "RUSH" or 
"URGENT" wr i tten disti ncl y somewhere on the request and 
must be coded as such. (See Data Element List.) 

4. PAC - If "LC - 0" or "LC - OX" is written on the request, 
code 1 after PAC. 

5. PO - If any of the notes in the list shown in the Data 
Element List are written on the request, supply the appropri- 
ate number or numbers (multiple notes are possible) after PO. 

6. RNi -Code RNI if the request carries an instruction to 
’notify’ the requester. 

7. CLT - not currently used. 

8. DES - not currently used. 
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9. ADD - Unless a note Is written to the vendor that the 

book Is to be mailed to an address other than Stanford# ADD 
Is coded as 1. If a note is written,, see Appendix II at the 
end of the Data Clement List. (Note: This rarely occurs# 

but watch for It.) 

10. STA - not currently used. 

11. LNK - not currently used. 

12. ORD/ MR I - 

a. If the request Is an order of any kind# cross out 
' MR 1 , 1 Next supply copy and bibliographic descriptor 
information as required for ORD as described in the 
Data Element List. 

b. If the item is an approval book and has# therefore# 
already been received# cross out ORD. Then code the 
information regarding the material received as shown in 
the Data Element List. 

13. I VR - not currently used. 

14. ID - Check to be certain that the identification number 
is readable. It is also a good idea (before even begin- 
ning to sort the sheets into categories) to scan the 
coding sheets for duplicates. If the duplicate is caused 
by accidentally xeroxing two copiec of one sheet# destroy 
one copy. If the duplicate is caused by accidental miss- 
numbering# take one copy down to the Acquisition Division 
secretary and ask her to assign a new number. If a 
coding sheet does not have a number# take it to the same 
secretary to have a number assigned. 

Note: The following instructions refer to the preprinted 

mnemonics in the SUL-25 area of the coding sheet. If LC 
data Is available and xeroxed on the coding sheet# do not 
code bibliographic elements from the process slip or SUL-25 
unless spec i fi ca 1 i y requested by Acquisition. Bibliographic 
elements which are coded from SUL-25 request slips even 
when LC data is available are PUX and SPO. 

15. CF# CA# A - Conference Author# Corporate Author# and 
Personal Author name 



a. A - Personal Author Name 

1. Form: Surname# Forename# Initial# 

Numeration# Suffix title# Prefix title# 
Dates# etc. 
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(i.e., Churchill, Winston Leonard Spencer, Sir, 

1874-1965.) . 

2. Punctuation: Use commas to separate 

sub-elements. 

b. CA - Corporate Author Name 

1. Form: Name, Subordinate Unit, etc. 

c. CF - Conference Author Name 

1. Form: Name, Number, Place, Date, 

Subordinate Heading, etc. 

16. T - Title 

Title Is not coded In the acquisition information If LC 
Information is available. 

a. Form: Short title, Sub-Title 

b. Punctuation: Insert where needed. 

17. TU - Uniform Title 

Although not preprinted on the coding sheet, the acquisition 
title can be a uniform title. 

18. ED -Edition Statement 

Ed*t out any repetition of the word, or abbreviation of, 
edl tion. 

19. PP - Place; Publisher 

Place and publisher must always be in that order. The 
correct order Is sometimes reversed on approval process 
slip so watch for this. 

Most Important, always separate the place from the publisher 
with a semicolon (cf. PUX). 

. 20. D - Date 

See Appendix B for more information on the use of D and DS. 

21. PR - Total Estimated Price 

Ordar Department searchers should pre-code this (see Appendix 
D) but check to see that it is correct. if multiple 
prices are given, add them and code the total. The 
abbreviation "ea." for each, after the price, is accept- 
able. Price may be left blank. 

22. BAC - Budget Account Code ;V 

If there Is no account code given, ask Fred Lynden in the 
Order Department to provide one. One exception: Hopkins 

Marine Station requests are acceptable without a budget 
account code. 
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23. SHE- Shelving Location 

Always coded. Should be pre-coded by searchers (see Appendix 
p>. Check that the searcher has written the mnemonic 
code. 



If multiple shelving locations are given code each location 
separately. 

24. VSP - Message to Vendor 

RUSH/ for instance/ is always coded as VSP. Code any other 
message to vendor as VSP. 



25. RT - Remainder of Title Statement 

Code as RT data after the subtitle and before the edition 
statement. An example is Edited by Theodore Smith. 

26. PUX - Additional Acquisition Information 

If the distributor is mentioned in the Acquisition \ 

Information but is not mentioned in the LC information/ 
it is coded as PUX. However/ if acquisition information 
only is supplied to be coded/ then the distributor is 
included within the code PP. 

27. SSI/ SPO - Series Statement/ Special Series Acquisition 
Information 

a. Use SSI to code series statement data. 



b. SPO - not currently used. 

28. RID/ IMP - Requester Identification Number/ Imprint 
I nformat ion. 

a. RID - Use standard 1 ist of identification mnemonics 
for high volume requesters. 

b. IMP - Use IMP to code special acquisition imprint 
Information such as reprint data, etc. 

29. RN - Requester Name 

Use RN for requesters who do not have an RID mnemonic 

30. RAD - not currently used. 

31. VCT - Vendor Catalog Information 

Use to code catalog name and item identification data. 

32. VID - Vendor Identification Number 

I dent i fi cat tori number for frequently used vendors. 

See vendor ID list. 
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B. LC B i b 1 iographlc Data 
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l . Main Entry. 

A. A Personal author name. . ■ 

1. Surname, Forename, Initial, Numeration, 
suffix title, prefix title, dates, etc. 

eg. Churchill, Winston Leonard Spencer, Sir 
1874-1965. 

2. Punctuation: use commas to separate 

sub-elements. ... 

I riser t periods after Initials/ etc. 

B. CA Corporate author name. 

1. Form: Name, subordinate unit, etc. 



C. CF Conference author name. 

1. Form: Name, Number, place, date, subordinate 

headings, etc. 



D. T Title. 

1. Form: Short title, sub-title. # 

2. Punctuation: Use punctuation of original 

information. ... . . , , j 

3. T is singular and is used to code the established 

form of the title. 

E. TU uniform title. 

I I . Body of card. 

A. T Title. Includes title and sub-title. 



B. 



D. 



RT Remainder of title statement. Includes a’ 1 , 

information occurring after the title and sub-title 
before the edition statement. . 

eg. Edited by J.E. Jones. 

ED Edition statement, 
eg. 4th ed. 
eg. Newly rev. ed. 

PP Place/Publisher. Repeat the attribute for e a ch _ 
separate pi ace/puhl i sher group. Use semicolon ^separate 
place from publisher. Code i n such a way that the first 
group is input first, the second, second, etc. See 
number 5 under General directions. Edit out semicolon 
between place/publisher groups and before the bracket 
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in the following example: New York, Cobble Hill Press 

(distributed by Hill Si Wang, 1968). 

E. D Date. Cataloged statement of imprint date. If 

there is no date do not code D, If the imprint date 
is a roman numeral or some other unrecognizable date, 
code the date in the imprint as DS and supply a date 
in D . 

eg. (1968, 1969) 

See also the discussion of attribute D (date) under 
XI. Implicit Bibliographic Description. 



III. Col lat ion. 

A. PR pagination, eg. iv, 191 p. Do not code PG for an 
open entry. 

B. ILL illustration. eg. !11 ms., maps (part fold.) 

C. SIZ size. If half size is given cross out and go to 
next whole number. 

eg. 24cm. 



IV, Series. 

A. SSI Series statement as giyen on order form or in 
series position on LC Card after collation. 

eg. iv, 196 p. 23cm. (McGraw Hill science series) 
SSI is singular. 

B. SNI series note as given in first note position. 

SNI i s mul ti pie. 



C. SEI series added entry. Use to code the series added 
entry if that entry is in a different form from that 
which is indicated in SSI. This does not have to be 
added to the TI (tracing indicator); SEI is always 
considered traced. 

V. Notes. 

A. GN General Notes. Formal bibliographic notes of a 
general nature. 

eg. Stamped on t.p.: New York, Harper. 

If there are more that 400 characters in GN make the 
note into two or more notes. 



B. 



NC Contents Notes. 

eg. v. 1 . The man 
there are more than 



n the moon. -v. 2. The sea. If 
300 characters make the note into 
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two or more notes. Code In such a way that the p"rts 
of GN will fall Into proper order when input. 

C. BIB Bibliography Notes. Cros.s out bibliography, 
eg. p. 31-33. 

0. SBN Standard Book Number 



VI. Added entries. 



A. SS Subject. Each subject heading (Arabic nos.) is 
coded SS; SS is always considered traced. 



B. Other added entries (Roman numerals) 



1. . Title. If the same as the title coded in the 

body, line out and do not code. Add the value 
T to the tracing indicator Tl. 

2. Title Added Entry. An alternative form of the 

T.P. title. Line out Title: Code as TA. Add 

value to Tl . 

eg. II. Man and Ape. Tl * T, TA. 

3. Author-Title Added Entry. Code author and title 
as A, CA, or CF. If the title is to be indexed 
separately, also code the title as TA; Do not add 
TA here to T I . 

eg. III.McLuhan, Herbert Marshall, The Medium 
is the Massage. 

4. Added Author. Code appropriately as A for personal 
author, CA for corporate author,, CF for conference 
author. Add these to Tl also. If any of these is 
the 2d or 3d A, CA or CF code as A, CA or CF but 
add to Tl as A2, CA2, CF3, etc. 

5. Series. 

a. SEI used to code series added entry if that 
entry is in a different form from that wh i ch 
is Indicated in SSI. Code SEI but do not add 
to Tl . Cross out series. 

b. SSI in added entry is series in the same form 
as in series statement. SSI Is not coded but 
is added to Tl. Cross out series. 

VII. LC Information. 

A. LC = LC Call No. Code all call nos. except Dewey, 

PZ1-4 or P nos. in () or any LC No. in ( ) 

eg. F2258.G3 1966. 

B. CRD LC Card No. 

VIII. Indicator Attributes. 
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A. ME Main Entry Indicator. Code at bottom left of 
bibliographic LC Card. 

eg. ME = a (if personal author is ME) 

B. Tl tracing indicator. Separate sub-elements by a 
comma. Code at bottom right of bibliographic LC card. 

eg. Tl = a2/ca/t. 

IX. Implicit bibliographic description. 

A. TYP type of work (see attribute list) 

B. FRM form of reproduction (see attribute list) 

C. CNT form of content (see attribute list) 

D. CP country of publication. If U.S. leave blank (U.S. 
by default) The country is of the first place named in 
the imprint. 

eg. London/ Mew York; Academic Press. Code EN for 
Eng. 

E. L language 

1. Language (s) English assumed by default. 

2. Language (s) of summaries, 
eg. 1 . F.ng. f re; 2Rus . 

3. Separate categories by semicolon. 

F. TR translation. 

1. Language of the text. 

2. Language from which the text was translated. 

3. Original language if different from the language 
from which the text was translated. 

. Language (s) of summaries. 

G. GOV government publications indicator. 

H. X index indicator. Used to indicate the work 
contains an index to itself. 

I. D date. Must be filled in v/hen imprint date is 
unrecogn i zabl e. 

J. XT incomplete record. Diacritical marks not 
Included. Check 1. 

K. PRE Precataloging indicator. Always check 1 when 
bibliographic information from an LC card. 




?.06 



235 



GENERAL DIRECTIONS 

1. Edit out superfluous .Information. 

eg. Bibl lography: 

SBN 

Roman or Arabic numerals In tracings. 

Title 

Title: (alternative title) 

(series) In tracing 
Series: SEI 

Contents 

2. Always edit personal name for following: 

a. Supply periods after initials, 
eg. Jones, James B. 

b. If any other information besides name is present, name 
must be del I m I ted by second comma. 

eg. Smith, John, 1500-1967. 
eg. Henry IV, King of England. 

c. Move prefix title. 

eg. Churchill, Winston Leonard Spencer, Sir 1874-1965. 

d. Author-title added entry. Supply 2d comma. 

eg. McLuhan, Herbert Marshall, The medium is the 
massage. 

3. All like attributes must be input together. If the main 
entry is a (personal author) and there are two other A's 
(personal authors) in the added entries, they must be indicated 
cit the top of the coding sheet as A3 so that the Input operator 
will input all three A's at the same time. 

4. Draw lines to first word of an attribute value; draw lines 
clearly and legibly to facilitate input. 

5. For PP, GN, NC, code attribute so that the order of the 
information is preserved. 

6. I terns on card not coded: open entry in collation, price. 

National bibliography numbers, any bracketed information on 
bottom of card, Devey call nos., PZ 1-4 or P nos. in ( ). 

7. If attributes are bracketed, edit in such a way that each 
attribute has an initial AND final bracket. 
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B CLARIFICATION OF THE USE OF D AND DS 

The value of the attribute 0 is indexed as an access point 
for the In Process File. The value of OS is never indexed., 

D is used tocode an imprint date which contains a date 
capable of being indexed by the file building program. For 
example, dates in forms such as <1968>, cl968, 1968-, 1968 
<cl968>, 1968?> 1968 are indexable and are coded as 0 for either 
acquisition only or L.C. bibliographic data. 

DS is used to coda an imprint date which is not in an 
indexable form. In this case, the Data Preparation Coder will 
supply a date coded as D. However, the coder will also precede 
the supplied date with a pound (#) sign. All information 
following a pound sign is suppressed during printing so that, in 
this case, the date will not be printed on the purchase order and 
yet will remain in the computer file as an index point. 



C PROCEDURE FOR EDITING AND CODING VENDOR NAMES AND ADDRESSES 



Due to the cost and the time required to maintain an ever 
growing computer vendor file, a new procedure on coding vendor 
names and addresses will be followed effective Immediately. Data 
preparation will no longer continually add vendors to the computer 
file. The new computer vendor file contains a select set of 68 
most commonly used vendors. (A listing of these vendors is avail- 
able on request.) Vendors on this list will be coded, as before, 
by I ,D. number (VID). Vendor names and addresses not on the list 
• of 68 vendors will now be coded with the mnemonic codes VN (Vendor 
Names) and VAD (Vendor Address). 

The Data Preparation Coder will 

1. Check the Computer Vendor File Listing for the 
vendor assigned on the coding sheet. ; 

2. If the vendor is on the list, code the vendor 
identification number as the mnemonic Vlj). 

3. If the vendor Is not on the list, verifyj the 
correct vendor name and address from the? Rolodex 
Vendor File in the Order Department or from Fred 
Lynden if the vendor is not on the Rolodex. (Note: 

This step in the coding process will be done in 
batch after all other coding has been completed.) 

Code vendor name and address as mnemonics VN and 
VAD, according to the following rules: 

a. There can be no more than six (6) lines in the 
address (including the name). 

b. Each line is limited to 31 characters in length. 

c. The end of one line and the beginning of the next 
line will be indicated by a semi-colon (;). 

d. If the address is foreign, the country will stand 
alone on the last line in all capital letters. 

e. U.S. addresses will have a zip code two spaces 
after the state. 

f. Avoid .abbreviati ons unless absolutely necessary. 

Note: Sample vendor name and address after editing - 

Gal 1 and I ngl is 
13 Henrietta St. 

London, W.C. 2, England 
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Appearance of name on computer output: 



Gal 1 and I ngl i s 
13 Henrietta Street 
London, V/.C. 2, 

ENGLAND 

Mote that it is no longer necessary to assign new 1,0. 
numbers or to create file cards for new vendors. 

Example of a U.S. address - 

GSA 

P.0. Box 1719, Boulder, Colo. 

80302 



Appearance on computer output - 

Geological Society of America 
P.0. Box 1719, 

Boulder, Colorado 80302 

Note: The terminal operator wi 1 1 he trusted to insert two spaces 

between the state and the zip code. 
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D SIMPLE PRE-COD I MG FOR ORDER DEPARTMENT SEARCHERS 

In order to facilitate the task of coding for Data 
Preparation it would be appreciated if Order Department searchers 
would provide the following small bits of information on the 
SUL - 2 5 cards. 



2' 

■/- 






RUSH-RE SERVES 



Amhor ^ McHarg> Jan L. 

Design with nature. 



Title 



Edition 

V. 



rir.ee 



Publisher-. 



Garden City, N, Y^fjNatural History Press 



Date of Publication . 

1969 



No. Vols 
200 p. 



Series 



iS*o. Cop. 

—.3 


Price 

_„425.00, 


Kcq. by - 


ETIassen 


Dept 


CE 




Morris 


Acct. 


NWC 201 


Ensiueering 



Order From : 



Other Info.: 



Item: 



Searcher: 



Ck 



-a, 



1. AUTHOR AND TITLE 

Check to see that each contains end punctuation; l.e., 
period, question mark, etc. 



2. EDITION 

It is not necessary to repeat the English abbreviation 
"ed." It is sufficient to write just "2nd", "2nd rev.", "2, 
verb. Aufl.", etc. 



j 3. PLACE; PUBLISHER 

Always separate the place from the publisher with a 
semicolon. 

-* 4. PRICE 

If there is no doubt that the price is U.S. dollars then 
please write the price with. the dollar sign, the decimal 
point, and the two zeroes if necessary. For example, instead 
of $25. or 2500, write $25.00. 

If the price . is in foreign currency, write in the foreign 
symbol; i.e., FL., DM, etc. When in doubt as to the nationality 
of the currency, just write whatever is known. 



5. 



1 

I 



| ERLC 



SHELVING LOCATION 

Write in the mnemonic code for shelving location in capital 
letters after the spelled out shelving location, (See 
directory of Mnemonic Codes for Shelving Locations.) For 
example. Falconer Biology FAL or Physical Education for 
Women Library PEDW. Since the reques.t cards are xeroxed 
onto the coding sheets, it is important that the searchers 
write or print clearly and press firmly with the pencil. 
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DIRECTORY OF MNEMONIC CODES FOR SHELVING LOCATION 



o 

ERIC 



i 

u 


LOCATION 


■ MNEM. 


1 

) 


I j Archive of Recorded Sound 


ARS ! 




l Area P 


LOCP | 


i 


Art Library 






1 i Asian Languages Library 


ASL ! 


r" 


U Auxiliary Collection - B 


AUX3 | 


i 


Bivphysics 


BPHY | 


i 


Branner Geology Library 


BRAN |j 


\ 


■ j Briggs Memorial Library* 


BRIG 1 


{ 

I 


British Documents 


BDOC • 


i- 


r* * Catalog Division 


CTDV j 


! 


Chemical Engineering 


CENG j 


i 


“Classics 


CLAS 1 


u 


t Communication - Journalism Library 


COM l 


j Computer Science Library 


COMP i 


j. 


1 Cubberley 


CUB jj 

DUDH 1 

EENG 


:■ 


Dudley Herbarium 


f f 


{ Electrical Engineering Library 


; 1 


. i Engineering Library 


ENG | 




Engineering Economic Planning 


EEP l 


1 f 


K^Falconer Biology Library 


FAL jj 


\ ( 


\j Felton Library 


FELT j 




• Filmstrip 


FLMST | 


[ [ 


1 Food Reasearch Institute Library 


FRI | 


u 


| Government Document Division 


GOV 3 


s 


Graduate Program in Humanities 


GHUM j 


? i • 


. Guggenheim Aeronautics 


GUG j 

GNST | 

HANS | 


j 1 


j Gunst Memorial Library 


ff 


■ Hansen Laboratories 


1 

r 

f smmd 


Hopkins Marine Station 


HMS 1 


n 


| Institute of American History 


IAH | 


i, i. 
1 


i Jones Room 


JNS 


Locked Stack 


LOG 1 


t f 


] Mathematic - Statistics Library 


MATH [j 


i 


J Microtext Room 


MTXT [j 


p 

& 

?? 


Modern European Language Collection 


MEL i 


a 

j | 


| Music Library 


MUSC B 


J Newspaper Room or Current Periodicals 


CPER | 


1 


Newton Collection 


NEWT | 


u 


*, Nuclear Technology 
1 Phys. Ed. for Women Library 


NTECH j 
PEDW 1 


; I 


1 Physics Library 

Plasma Physics Library 


PHY j 

PPHY • | 


( Radioscience 


RADIO S 




J Rare Book Collection 


RBC 1 


i /^Rare Book Collection Reference 

i Up ■ ■“ ,B 


RBCR jj 



LOCATION 



MNEM. 



Reference Room 



Solid State Library 
Stack 

Stephen Timoshenko Library 
Swain Chemistry Library 
Systematic Biology 



RR. . 

solid" 

STK 

TIMO 

SWAIN 

SYST 



Tanner Philosophy TAN 

West Library of Political WEST 

Science 



February 19, 1969 
(Revised October 20, 1969) 
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E CODING OF AUTHOR(S) IN ACQUISITION INFORMATION WITHOUT AN 
v LC CARD 

, If the acquisition infomation on the coding sheet contains 
an author and title such as - 





Aulbot p e .3 us i <) ft. £ib. 

Title /)1o/ecuUr gene.'/'i'c-s , b \i fl- G-ih 
Oe-BosK 




Edition | 


1 Place Publisher 



The r epea ted author in the title will not be coded. 

ft 

T- 



l 


Oe. Busk, ft (Ji cJ. 

fY)0 l&r $e.n&ti c.s. y 

Ber&vsfc- 





Edition 



Publisher 




However, if the repeated author after title is not 
immediately recognizable as the main entry author or if there are 
multiple authors (editors, compilers, translators, etc.) which 
are not included in the main entry, the author or authors will be 
coded as RT (Remainder Title Statement). 



F> 

r- 



n~o!stoi f Niko lc\e-Vic-h) 

2%-bjaranJ peQe.e. 4g (b\j LeoTolstot 



by George. K&dvJ&s 

Inti p||CC * Ptthlilllltr 



Edition 



Publisher 



7?r : 




Or 



ft 

T- 



T 

'ClOirKe.) Geh£./ 7 ) v £J. 

Tiu^ /1 Qodgrn Cinema.; fliod 

Cri+ic-ism^ceJ. C.m. 

: 1 in ii w i u — H. . 



Edition 



Place 



Publisher 
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F DATA PREPARATION EDITING SYMBOLS 



As an aid for all those working with coding sheets, the 
following editing marks v/i 1 1 be used by Data Preparation and will 
be observed by Data Control during input. 

OPERATIONAL SIGNS 



MA,RK 


ACTION 


EXAMPLE 


RESULT 


or 


Delete 


Born Free^’"" 


Born Free 




Close up; 


Everybody 


Everybody 




delete space 


V-/ 




V 


Insert space 


K i ngGeo rge 


King George 


<$> 


Spe 11 out 


Texas (uT^ 


Texas University 










At±+. 


Let it stand 




Trans. By 


Q 


Paragraph 


<1 Now is the time 


Now is the 




for all good men 


time for all 








good men. 


^9 


Run paragraphs 


To come to the 


To come to the 


together 


aid of their 


aid of their 






party. 


party. Last 






Mm $ Last year. 


year, the elec- 






the election 


tion was etc. 






was etc. 




TYPOGRAPHICAL SIGNS 






/ 


Lower case 


jfovie rcase 


1 owe rcase 




Capl tal Ize 


capl tal ize 


Capi tal i ze 


A 


1 nse r t 


Q 

Ballots Wylbur 

A 


Bal lots. Wylbur 


ta 


T ranspose 


Hap(ifp)ness 


Happiness 




Set In same 


Thj? storv of mvj 


The story of my 


s — 


line (or in same 


/'’’(N.Y.; MacMi Ilian) 


1 ife as tol d etc . 




mnemonic code) 


'*■^1 i fe as told etc. 


(N.Y.; MacMillan) 
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G NOW-ROMAN SCRIPT WITHIN BIBLIOGRAPHIC INFORMATION 

\ 

If the bibliographic information on a coding sheet conta I ns 
non-Roman script for which no Romanized equivalent is given, the 
bibliographic information cannot be included in our system at 
this time. Should a coder receive such a coding sheet, she WI.LL 
code the acquisition information but the L.C. Bibliographic 
Information will be crossed out. A note will then be written on 
the request in the Order File - "Do not purple flag." 

Notes to Cataloging Regarding Coding 

By the same token, if for any reason it is necessary to send 
a message regarding coding of L.C. Bibliographic Information to 
the Catalog Department a message will be written on the request 
slip in the Order File. An example of such a note might be - 
"Tracing III. US. coded as CA." should cataloging decide that the 
tracing was coded incorrectly, they will then know that an Update 
Sheet is needed. 
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DIAGNOSTICS 



(from the input program) 




. . . . NORMAL END OF RUN t • 

termination with no noticeable program errors 

.... ABNORMAL END OF RUN 

termination due to a program error; please contact a member of 
the SPIRES system group. 




??? SYNTAX ERROR 

-a syntax error has occurred in input data: 

(1) an attribute name followed by something other than a quote 

(2) a reserved word (or attribute string value) followed by 
something other than a legal reserved word (or legal string 
value) 



--- END OF INPUT UNDER CONDITION 

-physical end of input data was something other than END or the 
■ DELETE statement. 

(NB diagnostics concerning DELETE syntax errors and attempts to 
recover from them have not been included.) 







??? ATTRIBUTE IN ERROR attribute name 
VALUE attribute value 

-these two lines precede any message involving incorrect attribute 
values; these messages are: 

??? MULTIPLE VALUES NOT CONTIGUOUS 

-within a given entry, multiple values for any given attribute 
must not be interspersed by any other different attribute. 

??? NO SET NUMBEER ALLOWED FOR ATTRIBUTE VALUE 

-illegal attribute (i.e. does not belong to given association 
group) given a set number 

??? SET NUMBER REQUIRED FOR ATTRIBUTE VALUE 

r incomplete use of set numbers within a given entry for a given 
association group of attributes 

??? VALUE MUST BE INTEGER 

??? ATTRIBUTE ASSOCIATED WITH VALUE IS SINGULAR 

-multiple values are not allowed for this attribute 

??? ATTRIBUTE VALUE IS AN EMPTY STRING 

??? AUTHOR NAME HAS WRONG FORMAT 

??? LENGTH OF VALUE TOO LONG 
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DIAGNOSTICS (page two) 

??? JVP FORMAT WRONG 

\ -journal, 1 volume, page format in citation is incorrect 

1 ? ?USE ONLY DT "1" FOR CITATIONS 

The following dianostics do not refer to only one specific attribute name 

and value: 

??? RESENT PROGRAM LIMIT OF 200 CITATIONS PER PREPRINT 

??? INPUT STRING TOO LONG FOR BUFFER 

-may be caused by a missing quote on an attribute value; if problem 
persists, contact SPIRES system group. 

??? NCl OF SETS FOR EACH ATTRIBUTE IN AN ASSOCIATION GROUP MUST BE EQUAL 

??? ATTRIBUTE DESCRIPTOR TABLE PROBLEMS 
-contact SPIRES system group 

??? ENTRY TOO LARGE FOR DATA BASE BLOCK 
-contact SPIRES system group 

??? WARNING TRANSLATED TITLE USED WITHOUT LANGUAGE ATTRIBUTE 

??? WARNING attribute name ATTRIBUTE NOT FOUND 

-these warnings are to indicate to the user any indication of 
possible input error not considered serious enough to keep the 
entry involved from being placed in the data base! 

(from INDEX) 



value DOC TYPE CAUSED A CONVERSION ERROR 

value SOURCE CAUSED A CONVERSION ERROR 

-Document type (for PPT file) and source are expected to be numeric 



(from 



lAi i 



D 

0 



o 

ERIC 



STATISTICS CANNOT HANDLE THIS INDEX FOR THIS USER 

DO NOT HAVE A STATISTICS FILE FOR THIS DATA BASE 

NO STATISTICS TAKEN PAST ATTRIBUTE # value 

DO NOT HAVE A STATISTICS FILE FOR THIS INDEX 

-For these and any other diagnostics not listed, contact the SPIRES 
system group 
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Use of SAJGE 



SAJGE (pronounced: sajjy), is the SPIRES automatic Job 

Control Language generating system. It is currently used by • 
the Data Control Supervisor to prepare data base update* and 
tape dump programs on a regular schedule. 

In the midst of an experimental and rapidly developing 
system with many different users, a facility like SAJGE allows 
JCL changes to be made more easily by the systems programers. 

It also provides the user file managers (such as the Data Control 
Supervisor) with a simplified way of setting up program runs, 

SAJGE draws heavily on ORVYL, the Stanford Computation 
Center Campus Facility* s time sharing monitor. The system 
prompts tho user with a series of consecutive options. In 
this way the user is lead to specify the SPIRES program and 
files to be used, and the appropriate run time parameters. 

The user is informed before each prompt which options 
are available. Responses are made to the. ALTERS? prompt as 
normally used in WYLBUR, the text editing facility, 

A printout .showing the use of SAJGE to copy t.lie In 
Process File from disk to tape is attached- 



* * * 

You have entered SAJGE/ a JCL generating system. 

Spires Programs currently (as of 9-4-69) supported under SAJGE are 

CPYFILE used to copy SPIRES DISK FILES to TAPE FILES or 

vice versa 

LSTFILE used to list SPIRES DATA BASE and INDEX files 

Using WYLBUR MODIFY CHARACTERS Cr/d,!)/ change "progrm$" to the 
desired supported program: 

1. USE &F820.JCSS. LOAD. START. progrm$ ON FILEH CLEAR 
ALTERS ? repyf i le 

1. USE &F820. JESS. LOAD. START. CPYFI LE ON FILEH CLEAR 
ALTERS ? : 




You have chosen the SAJGE option which copies Spires Files. 

Change "typ$" to one of these parameters: 

DSTP for copying (dumping) from disk to tape 

TPDS for copying (restoring) from tape to disk 

Change "ur$" to your User Mnemonic ( I PF^PPT/ERC/GFO/HST/or TST). 
Change "see#" to the Stanford Computation Center No. for your tape. 
Change "n#" to the 2-digit Spires No. for your tape. 
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1. USE &F820. JESS. LOAD. START. CPYFILE.typ$ ON FILEH CLEAR 
ALTERS ? rdstp 

1. USE &F820. JESS. LOAD. START. CPYFI LE.DSTP ON FILEH CLEAR 

ALTERS ? 

2. COPY ALL TO END FROM &F820 .JESS. LOAD. USER. ur$ ON FILEH 

ALTERS ? rlpf 

2. COPY ALL TO END FROM &F820 .JESS. LOAD. USER. I PF ON FILEH 
ALTERS ? 

QUEUED 

11. - LAST LINE. 

17. - LAST LINE. 



2. 


CH 


•SCCQ' TO 'see#' IN 1 


NOLI ST 


ALTERS ? 




r2641 




2. 


CH 


' SCC@ ' TO '2641'' IN 1 


NOLI ST 


ALTERS ? 




'TAPE(d^' TO 'TAPEn#' 




3. 


CH 


IN ALL NOLIST 


ALTERS ? 




r07 




3. 


CH 


' TAPES® ' TO 'TAPE07' 


IN ALL MOL 1ST 


ALTERS ? 









QUEUED 



Now modify your JOB card/ filling in acct. no./ bin no./ minutes/ 
thousands of lines/ hold status (T/D/ or B)/ and name. 



1. //DMP2641 JOB (act%/bn#/m#/ 1#////$)/ 'your$ name$ ' /MSGLEVEL=1 

ALTERS ? rf829/439/15////fr 

1. //DMP2641 JOB (actf 829 / 439 / 15 / / / /It) / ' you r$ name$ ' /MSGLEVEL=1 

ALTERS ? rf 829/ 439/ 15/ 15/ / / /** 

1. //DMP2641 JOB (F829/439/15/ 15////*rr)/ 'your? name$'/MSGLEVEL = l 

ALTERS ? d dirobbie 

1. //DMP2641 JOB (F8 29/4 39/15/15// / /’if) / ' ROBB I E' / MSG LEV EL* 1 

ALTERS ? 



Now submit this job. Save this JCL until the job has been run 
successfully under YOURNAME. JCL. JOBNAME. Do not modify this JCL for 
future runs. Send the operator appropriate mount instructions 
including see tape no./ Spires label/ 9-track/ read or write/ acct no. 
and the job no. 1 
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THIS IS THE PROCEDURE FOR ADDING TO THE VENDOR ADDRESS FILE 



After following the SIGN-ON procedure/ please SET LENGTH = 
36; SET TABS = 5; and SET UPLOW. Then USE GLEE. VEND. JCL on 
FILEH. DELETE line 10/LAST and COLLECT in the new data in 
the following format; 

I A1072 

International Metallographic 
Society 

ATTN: Publications Committee 

P.0. Box 219 

Los Alamos/ New Mexico 87544 

end 

f * 1 

/ W I 



The I for Insertion must be in column one. (1). 

There must be at least one (1) blank between the insertion 
coding and the actual vendor number. 

There must be at least one. (1) blank before starting to 
type the vendor name and address. For sake of consistency/ 
please use the SET TABS feature to begin the name and address 
lines in column five (5). 

All foreign country names should come alone on the last 
lines of the address. 

There may not be more the six (6) lines per entry for 
the name and address. 

There may not be more than thirty-one (31) characters per 
line in the name and address. Please use the SET LENGTH 
feature for length warning. The 31 characters do not include 
the blanks proceeding the name and address. 

Do not abbreviate, except where absolutely necessary. 

There should be two (2) blanks between the state name and 
the Zip Code in United States addresses. 

The END statement must begin in column one (1). 

The last card should be a '/** card. 



For Backup purposes please copy the new vendor names and 
addresses into the end of the file names VENDORFi LE. MASTER. <date> 
on FILEH. In order to locate the last date, simply use the 
SHOW DSNAMES LIKE VEND ON FILEH command. This will give you 
the last complete name of the masterfile. Then after copying 
in the additions to the file, please SAVE VENDORF 1 LE. MASTER. 

<c.ur rentdate> ON FILEH and SCRATCH the old master file. 

In order to process the additions to the file first save 
the JCL and your additions in the form VEND.<currentdate> 

ON FILEH. Then use the Command RUN UNNUMBERED. This will 
enter the job into the 0/S batch to be processed. 
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XJ 



li 



D 

0 

0 

II 

0 

D 

(I 

0 




CD 

to 

CM 
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ACQUISITION/CATALOG UPDATE REPORT ^ 
Mnem To 



Value 



m 


Copy Number 


Volumes 


Call Number 


Variation 


Status/Date 


• 


• 


• 

.9 


• 

_ J 


• 

9 




• 


* 

* 


• 

9 


• 

« 


• 

- * 




• 

V 


• 

* 


• 

* 


• 

> 


• 

L 





Coder: 
Term Op. : 



Name 


Date 
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■I J 

0 

0 

, j 

Li 

0 

iJ 

Q 

0 

0 

0 

D 

0 

0 

0 

0 

0 

i! 



CLAIMING INFORMATION SHEET 



I.D. No. 

CLD: (add) DATE j 

OBJECT OF CLAIM (M or I) 

Bibliographic Descriptor and Copies, 



Manual Indicator ~ M 



OTHER: ADD/ CHANG? /DELET E 



CODER SAME: 

BALLOTS — update— CLI—L 
4 - 1-69 



l «. , 257 



j 




1 / 
I [ 




i; 



0 

0 

D 

I) 




tKLC 



CANCELLATION INFORMATION SHEET 

I.D. No. 

CAN: (add) EATE 

/ TYPE 

BIBLIOGRAPHIC DESCRIPTOR & COPIES 



CANCELLATION REQUESTOR NAME ; 

REASON FOR CANCELLATION J 

VENDOR 

PRO: (change) REISSUE P.O. NOW? Yes No (circle 

one) 

VED: (change) CHANGE VENDOR TO 

M3V: (edd) MESSAGE FROM VENDOR 



OTHER: (add/ change/delete) 



CODER NAME: 

BALLOTS— update— CIS--1 
4-1-69 
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m 

N> 

\o 



*o 

01 

0) 
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t : '• \ ■ • : 



I VEND. 
NO, 



BIU IN DUPLICATE TOr °* D£R ^STANFC 



= \ OEAlCt 


INV. DATE 


if. 


n.p. 


S, rx. 


SP. 




i lcave ► 

, tiANK 












DEALER: SEE 
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o 
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1. 

2. 

3 . 

4 . 



Show our order number on all packages, correspondence and invoices. 

Return Dealer Report inside front cover of book. Please report promptly if order * 
will be delayed, or otherwise is irregular. 



O' 

o 



Report before sending if price is appreciably higher than the price shown on thi 

If an item ordered from the catalog has been sold, please return Dealer Report, 
able later, pfeasc quote again. 

Report before sending o reprint or' port of a series unless this is specified on th 
Unreporfed orders are considered cancelled by us if not supplied within six months. 



U f ' 



r; j i .j r 



■ j r: .. i r, ) 



0AT6 OF OROER 



ORDER NO. 



‘ 4 - 0 - 



eaii no n id • .'i : 

i V; rvwG :: •. 

* \i i? fVo b y ,i r. -«!i c *i> t : 



VEND. 

| NO. 



o 

o 

o 

o 

o 



~~77T7!r^rTT7TZ 'owe* dept. . Stanford university ubraries T 
Bill IN OUPUCATE TO: Stanford. California 94305 





IP. 


N,P. 


S. TX. 


S.P. 


SUL-20O 11-691 1 
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o 

0 

o 



o 



o 

o 

0 



TOTAl 
EST. PRICE . 



- DEALER 
LEAVE | 

blank 



VEND. 

NO. 



INV. DATE 


LP. 


N.P. 


S. TX. 


S.P. 


DATE RE CD. 












DEALER: SEE OTH 



ORDER DEPT. • ST ANFC 
BILL IN DUPLICATE /0* STANFORD, C 



TO THE DEALER; Please return this slip inside front cover of item ordered, if you cannot sup 
indicate reason(s) below and return this slip at once. 



□ Not yet published. 
Cl Out of stock. ‘ • 

□ Out at print. 

□ To be reprinted. 

. O Sold. 

□ Searching. 



Cl Order cancelled. 



□ Order on file. 

□ Probably available byi 
Cl Complete, discontinued 

“1 r* le 



□ Cost is 

□ Will quote 



Forms part of a series 

Author* correct name is_ 

Correci title is 

Reprint of 



G Not available separately. Do you want entire set? 
□ Other • 




r c *; 



) r vj r 



) f. ) f. 



DATE OF ORDER 



ORDER NO. 



r. . ) r. )■ 






o 



r._ .i 



0- 







t 


VEND. 

NO. 


«... ORDER DEPT. • STANFORD UNIVERSITY LIBRARIES 

BILL IN DUPLICATE TO: STANFORD. CALIFORNIA 94305 




N.P. 


S. IX. 


S.P. 


DATE REC . SUL-200 1 1 -69) 

DEALER: SEE OTHER SIDE 
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:-c return this slip inside front cover of item ordered. If you cannot supply, please 
iv/ and return this slip at once. 



ct published, 
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rt of a series 

orrect name is_ 
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D Order cancelled. 

□ Order on file. 

D Probably available byj 

D Complete, discontinued, merged, suspended. 

□ Cost is 

□ Will quote. 
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4 



PROMPT 



RESPONSE 



EXPLANATION 



Sample Searching Arguments using BALLOTS/ 



SEARCH? 



ipf 

preprint 

afhist 

geology 

eric 



Library (In Process File) FILES 

High Energy Physics AVAILABLE 

(African History) TO SEARCH 

Geology Periodicals 
(Information Center) 



FIND? 



a 


(Author) 


INDEXED 


ca 


(Corporate Author) 


DATA 


cf 


(Conference Author) 


ELEMENTS 


ti 


(Title) 




d 


(Date) (Subset of 


other index entries) 


id 


(ID Number) 




tp 


(Topic' (Not used 


for Ipf and preprint) 



OPTION? 



BACKUP? 



and 

not 

or 



(DATA ELEMENTS - see above) ! 

(LOGICAL CONNECTORS - see above) 
backup (returns search to previous step) 

restart (ciear3 present search) 

type (lists short form of output) 

type extended (lists entire copy) 



restart 

search 

type 

type extended 
exi t 

show news 



(dears present search) 
(continues present search) 



(exits user from SPIRES) 
(Lists out news about system) 



yes 

no 



LOGICAL 

CONNECTORS 



1. COMMAND? spires 

2. Welcome to SPIRES 

3. SEARCH? Ipf 

4. FIND? tl intimate 

5. TITLE WORD SEARCH FOR,.. INTIMATE 

6. 3 DOCUMENTS ) ACCUMULATED 

7. ? ti enemy 

8. TITLE WORD SEARCH FOR.. • ENEMY 

9. l DOCUMENT (S) ACCUMULATED 

10. 7 type extended 



LI. 


ID: 


2977-2 


12, 


AUTHOR: 


Bach, George 1 


13. 


TITLE: 


The intimate < 


L4. 


PUCE/PUBLISHER: 


New York; Moi 


15. 


DATE: 


1969 



16. 


OPTION? restart 




17. 


FIND? a george bach and a peter wydei 


18. 


? after June L968 




19, 


AUTHOR SEARCH ^0R 


... GEORGE BACH 


20. 


AUTHOR SEARCH FOR 


, , , PETER WYDEN 


2L» 


TITLE WORD SEARCH 


FOR... INTIMATE 


22. 


TITLE WORD SEARCH 


FOR... MARRIAGE 


23. 


DATE S RARCH FOR,. 


, AFTER JULY L, 196 


24. 


1 DOCUMENT(S) ACCUMULATED 


25, 


type extended 




26. 


ID: 


2977-2 i 


27. 


AUTHOR: 


Bach, George 


26. 


TITLE: 


The Intimate 


29. 


PLACE/PUBLISHER: 


New York; M 


30. 


DATE: 


1969 



to spires (Legal after all prompts except BACKUP? 

alLows user to send comments on the use 
of the system to the SPIRES group.) 

,, 2" serves as an implicit M and" between Lines. 

Search statements may be constructed on any word or words 
in the title, and on any form of the author which Includes 
surnames. 

Search statements may be continued beyond one line by use 
of the symbol 

Words and names may be truncated after the third letter by 
use of the pound sign: e.g. Smltf. 

Date searches must always follow another alement search. 
Date searches are formatted:d 1969: d before 1969; d after 

1968; d from 1965 thru 1968. 

Two digit* year representations and standard abbreviations 
for months are accepted. 
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3L. OPTION? restart 

32. FIND? a may 

33. AUTHOR SEARCH FOR.. » MAY 

34. 2 DOCUKENT(S) ACCUMULATED 

35. ? d before L920 

36. DATE SEARCH THRU L919 

37. 0 DOCUMENT (S ) ACCUMULATED 

33. BACKUP? yes 

39. SEARCH RESULTS RESET TO LAST 

40* ? d from L9L9 thru 1967 

4L. DATE SEARCH FROM JAN- L- 19 19 THRU 19< 

42, 1 DOCUMENT(S) ACCUMULATED 

43, ? type extended 

44, ID: 

45, AUTHOR* 

46, TITLE: 

4,7. PLACE/PUBLISHER: 

4B. 



4059-6 
May, Leopol 
Spectroscop 
New York; 



OPTION? exit 



I 



: ■ j 



f 'J f ) (3 



r ) r 







Sample Searching Arguments using BALLOTS/ SPIKES System 



Fite) FILES 

AVAILABLE 
TO SEARCH 

) 



INDEXED 

DATA 

ELEMENTS 

other index entries) 
for ipf and preprint) 



LOGICAL 

CONNECTORS 



>U3 step) 

}Ut) 



stem) 



except BACKUP? 
ments on the use 
IRES group,) 

n lines. 

m any word or words 
iuthor which Includes 

'ond one tine by use 

* the third letter by 

ler slement search. 

I before 1969j d after 

andard abbreviations 




1. COMMAND? spires 

2. Welcome to SPIRES 

3. SEARCH 7 ipf 

4. FIND? ti Intimate 

5. TITLE WORD SEARCH FOR.,, INTIMATE 

6. 3 DOCUMENT(S) ACCUMULATED 

7* 7 ti enemy 

8. TITLE WORD SEARCH FOR,,. ENEMY 

9. 1 DOCUMENTS ) ACCUMULATED 

10. 2 type extended 



11. ID: 

12 . AUTHOR: 

13* TITLE: 

14, PLACE/FUBLISHERl 

15. DATE: 



2977-2 

Bach, George Robert, 1914- Wyden, Peter, Joint author. 
The intimate enemy; how to fight fair in love and marriage 
New York; Morrow 
1969 



16. OPTION? restart 

17. FIND? a george bach and a peter wyden and ti intimate and ti marriage and 69 

18. ? after June 1968 

19. AUTHOR SEARCH FOR.,. GEORGE BACH 

20. AUTHOR SEARCH FOR,,, PETER WYDEN 

21. TITLE WORD SEARCH FOR,.. INTIMATE 

22. TITLE WORD SEARCH FOR... MARRIACR 

23. DATE SEARCH FOR... AFTER JULY I, 1968 

24. I DOClfMENT(S) ACCUMULATED 

25. type extended 



26, ID: 

27, AUTHOR: 

28, TITLE: 

29, PUCE/ PUBLISHER* 

30, DATE: 



2977-2 

Bach, George Robert, 1914- Wyden, Peter, Joint author. 

The intimate enemy; how to fight fair in love and marriage 

New York; Morrow 

1969 



31. OPTION? restart 

32. FIND? a may 

33. AUTHOR SEARCH FOR... MAY 

34. 2 DOCUMENTS ) ACCUMULATED 

35. ? d before 1920 

36. DATE SEARCH THRU 1919 

37. 0 DOCUMENTS ) ACCUMULATED 

38. BACKUP? yes 

39. SEARCH RESULTS RESET TO LAST 2 DOCUMENTS 

40. 7 d from 1919 thru 1967 

4L. DATE SEARCH FROM JAN-1- 1919 THRO 1967 
*2. 1 DOCUMENT(S) ACCUMULATED 

43, ? type extended 



44. ID: 

45. AUTHOR: 

46. TITLE: 

47. PUCE/PUBLISHER: 

48. OPTION? exit 



4059-6 

May, Leopold, comp. 
Spectroscopic tricks. 
New York; Plenum Press 
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6.6 Sample Analysis/Design Standards 

(referred to in subsection 2.5-1 
arid in sections 2.6 and 2.10) 

1. Data Elements Handbook 

2. Library System Notes Index 

3. Library System Note No. 18 
k. Computer System Notes Index 

5. Computer System Note No. 38 

6. Acquisition Study Contents plus 
Sample Pages 
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Project BALLOTS 

Subject: File Organization & Content 
Library System Note No. A (Revised) 

Name: Eleanor Montague 

\ Date: November 13 f 1968 (Revised July 18, 1969) 

, GUIDE TO MARC FILE AND IN PROCESS FILt. ATTRIBUTES 1 



MNEM 


S/M 


— 

INDE> 


C NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


A 


M 


PN 


Personal 
Author Name 


99 


^Name: Surname, Forename, Initial, etc.^ 

^Numerations 

<Suf f ix Title> 

^Prefix Titled 
<Dates> 

^Relator> 

{Form Subheading^ 

<Title of Work> Z 


AA 


M 


PN 


Variant form 
of Personal 
Author Name 


09 


See A 


ADD 


s 




Ship to 
Address 


60 


See Appendix II 


AE 


M 


PN 


Established 
Personal 
Author Name 


99 


See A 


*ANO 


M 


PN 


Name not 
Capable of 
Authorship 


300 


Change: New attribute 


BAC 


S 




Budget Acct 
Code 


7 


{6 Character Code^ 


BIB 


M 




Bibliography 

Note 


120 





'Items modified for this list are marked with an * and the change noted* 



See Appendix III for discussion* 
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MNEM 


S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


BUD 

1 

% 


M 




budget Amount 


50 


<Billed Amount^; 

^Bibliographic descriptors or S if 
same as 0RD7; 

. ST State Tax ; 

CT County Tax ; 

SC Shipping Charges 

Note: 1. If amount in foreign currency, 

code and v input foreign 
currency; no manual conver- 
sion will be made. 


CA 


M 


CN 


Corporate 
\uthor Name 


300 


See CAE 


CAA 


M 


CN 


Variant form 
of Corporate 
Author Name 


300 


See CAE 


CAE 


M 


CN 


Established 
Corporate 
Author Name 


300 


O'Jame^ 

Subordinate Unit7 
<Relator^ 

<Form Subheading '7 
^Title of Book ^7 


CAI 


M 


• 


Cataloging 

Approval 

Director 


14 


1 Approval of original cataloging 
information; <,cataloger 1 s initials ; 
date^ 

2 Approval of changes made to pre- 
cataloging information; ^cataloger f s 
initials ; date^ 


CAN 


M 




Cancellation 

Information 


70 


<Date^; 

<Type of Cancellation^; 

R Requestor 
D Dealer 
L Library 

(Bibliographic Descriptors 
J Number of Copies 4 L ; 

l 0R f 

if same elements as ORDj 



3 

See Appendix III for discussion. 

4 

For discussion, see "Representation of Volume, Part, Fiscicle, etc.", 
by Jerry West. or 
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- ■■ 1, 
MNEM , 


S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 1 

CONTENT 1 


CAN - 

1 1 


cont 


inued « 






^Name of person requesting cancellation^ 
< Reason for cancellation^ 


CAT 


M 




Cataloging 
Authority f 
Changes in LC 
Information 
or Notes to 
Catalog I/iv. 


240 


« 


CF 


M 


CF 


Conference 
Author Name 


300 


^Narne^ 

<Number> 

<JPlace^ 

<Date> 

^Subordinate Heading^ 

< Miscellaneous Information^ 
^Form Subheading '• 

<Title of Book-*> 


CFA 

t 


M 


CF 


Alternative 
?orm of 
Conference 
\uthor Name 


300 


See CF 


CFE 


M 


CF 


Established 
Conference 
Author Name 


300 


See CF 


CLA 

h 

— - 


M 




Claiming 
[n format ion 

• / 


70 


^Date of Clain>f 
<Type of Claim>; 

M Material 
I Invoice 

f Bibliographic Descriptor ^ 
J Information / 

J Number of Copies L 

I 0R f 

\j5 if same as ORD ft 



"*See Appendix III for discussion. 
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MNEM 


— 1 

S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


CLD 

* 


M 




Claim Date 


70 


<CIaim Date^; 

<0bject of CLaitn^; 

M Material 
I Invoice 

^Bibliographic Descriptor 
or S if same as ORD^; 

M Manual Indicator 


CLT 

i 

i 

i 


S 

j - 

t 

i 

i 

j i 

t 

i 

i 

i 

i 

i 

• i 


1 

! . 
j 
1 


Claim Type 

i 

i 

l 

i 

i 

i 


2 

1 

1 

1 


1. Rush Order 'Domestic) 

2. Rush Order (Foreign) 

3. Current American Imprints 

4. Non-current American Imprints 

5. Current Overseas Imprints (Europe) 

6. Non-current Overseas Imprints • 

(Europe) 

j 7. Current Overseas Imprints (Asia & 
j Africa) 

l 8, Non-current Overseas Imprints (Asia 
j & Africa) 

; 9, Latin American Imprints 
jLO. Standing Orders 
jLl. Invoices 

12. Partial Shipments (American) 

No dealer report 

13. Partial Shipments (Overseas) 

No dealer report 

14. Invoice and Material Received 

1 discrepancy 

15. Claim sent -- No Action 


CNT 


S 


* 


Form of 
Content 


3 


BIB Bibliography 
CAT Catalog 

IND Index (work itself is an index) 

ABS Abstract 

DIC Dictionary 

ENC Encyclopedia 

DIR Directory 

YBK Yearbook 

STA Statistical Compilation 

HBK Handbook 

PRT Programmed Textbook 


CP 


s 




Country of ^ 
Punlication 


3 


<2-3 Character Code> 

Note: 1. The country will be assumed to 
• be the United States by default 



o 

ERIC 



For place codes, see "MARC Place Codes" Prepared by Library of Congress, 
Information Systems Office, 1968. 269 
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MNEM 


S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


CRD 

< 


S 


M 


Library of 
Congress 
Card Number 


25 




D 


s 




Date 


64 


Note: 1. The date in D is the date 

indexed upon. 


DC 


s 




Dewey Class 
Number 


14 




DES 


M 




Desiderata 

Indicator 


2 


OP Out-of-Print, but wanted (Use with 
PRO X) 

NP Not yet Published 
OS Out of Stock 

X Out on Search in Manual System 

(Use with PRO X) 


DS 


s 




Imprint Dat* 


40 




ED 


s 




Edition 

Statement 


60 




FD 


s 




Date Enterec 
1PF 


l 10 


MM-DD-YY 


FOP 

i 

»; 


s 




Force 

Payment 


64 


^Bibliographic Descriptor or S if same 
as ORD^ 

Note: 1* Deleted by update program 

when IVP updated. 


FRM 


s 




Form of 
Reproductio; 


3 

t 


PHD Phono disk 
MTS Mag. Tape (Sound) 
MFM Microfilm Roll 
MFC Microfiche 
MOP Micro-opaque 
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MNEM 


S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


FRM 

1 


* con 


:inued 






MTA Mag. Tape (Date) 

OTH Other 

CLB Large Print 


GM 


M 




General 

Notes 


400 


# 


GOV 


s 


- 


Government 

Publication 

Indicator 


2 


U Federal {UjSg ) 
S State 

I International 
L Local 
F Foreign 


HN 


M 




Holding's 

Note 


40 


^bibliographic Descriptor?} 
<^Location> 








f 




Note: 1. "Informal” note for the 

control of uncataloged copies 
of material for which the 
library does hold cataloged 
copies. 


HOL 


M 




Holdings 

Information 


60 


<Call Number)?; 
^Location?; 
4Copy Number’?; 
< Status/Date^> 












Note: 1. Copy numbers will be given 

in the form: C*X* (C.l Under- 
stood by default.) 


ID* 

1 


s 

1 


ID 

• 


Identifica- 
tion Number 


10 


^1 - 7 digits)^ 

Note: 1. Required for IPF t 

Change: from MAX^8 to MAX«?10 


ILL 


s 




Illustra- 

tion 


90 




<3 













7 

Status Code: M - missing; L - lost; N - non-circulating. 
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MNEM 


S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


IMP 

% 


M 




Imprint 

Information 


100 




IVP 


M 




Invoice 

Payment 

Indicator 


50 


<Date >5 

^Bibliographic Descriptor or S if same 
elements as 0RD> 

Note: 1. Internally generated; 

not an input attribute. 


IVR 


M 




Invoice 

Receipt 

Information 


100 


^Date of Invoice Receipt^; 

^Invoice Number^; 

^Dealer date of invoice^ 
/Bibliographic Descriptor Information^ 
i Number of Copies f 

1 0R f 

if same as ORD J 


L 


S 




Language** 


48 


Language(s) ; 

Language(s) jf summaries 

Note?; 1* For subelement one alone, 
eng is assumed by default. 
2. For example: engfre;rus 


(lc 


S 

■ 




Library of 
Congress 
Call Number 


40 


i 

! 


LCA 


M 




■ Alternative 
Library of 
1 Congress 
Call Number 


: 40 

i 

j 

i 

i 


1 Change: New attribute. 

I 

i 

\ 


LNK 


'■ M 




Link 

Statement 


! 50 


i <Type of Record Linked to^s 
j <ID # of that record^; 

1 /^Bibliographic descriptor or, if not ^ 

l available, author ! s last name and short( 
j title (or both identifications if f - 

Vnecessary) (In Master Record) J 



For codes, see "MARC Language Codes", prepared by Library of Congress, 
Information Systems Office, 1968. 



MNEM 


S/M INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


* 

MAE 


S 


Converted 
from MARC 


8 


Change* From MAX=1 to MAX=8 


ME 


s 


Main Entry 
Indicator 


5 


^Attribute Mnemonic^ 
^Element Number^ 


MET 


S 


Main Entry 
in RT 
Indicator 


1 


1 Present 


MRI 


M 


Material 

Receipt 

Information 


70 


<Date of Receipt^ 

/^Bibliographic Descriptor Information} 
j Number of Copies ( 

1 OR f 

V*S if same as CRD J 


MSV 


M 


Message 
From Vendor 


240 


<J)ate^ 

^Message^ 


* 

NBN 


M 


National 

Bibliography 

Number 


20 


Changes New attribute 


NC 


M 


Notes -- 
Contents 


300 




NUC 


> 


Nat. Union 

Catalog 

Indicator 


1 


1 Send Notification 


ORD 


S 

L 


Order 

Information 


140 


^Bibliographic Descriptor Information}* 
(Humber of Copies ^ 

^Information Comments^ ; 

<Xanguage of Bibliographic Descriptor 
Information^ 10 


v An example would be: N 


ew Sei 


:ies 




For Language Codes, f, MARC Language Codes,' 1 Prepared by Library of 
Congress, Information Systems Office, 1968. 
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EF 


MNEM 


S/M 


INDEX 


NAME. 


AAX 

LTH 


CODES/FORMAT 

CONTENT 


ORD - 


conti 


nued - 






Note: 1. The language is considered 

eng by default. 


PAC 


S 




National 
Program for 
Acquisition 
and Cata- 
loging 
Indicator 


12 


1 Send Notice 

^Pate^ ; 

<Message^ 


PG 


S 




Pagination 


25 




PME 


s 




At Head of 
P.0. Entry 


5 


^Attribute Mnemonic^ 

^Element Number^ 

Note: 1, If entry to be printed at 

the head of the P.0. is not 
the main entry, PME will 
point to the information which 
is to be at the head of P.0. 


PO 

\ic 


s 


t 


Purchase 

Order 

Message 


10 


1 (for Serials): Subscription to 

begin with * 

and to continue until further notice. 

2 (for series, term, sets, open 

entries): and all 

future volumes as published. 

3 All volumes published and a standing 
order for future volumes 

4 Do not duplicate on University. Press 
standing order. 

5 Do not duplicate on Blanket order. 

6 Do not duplicate on standing order. 

7 Please quote on back issues. 

8 Please charge to Stanford University 
Library^ deposit account, acct. no. 

9 Prepaid 

Note: 1. More than one code may be 

included in P.0. Separate 
codes by a comma. 



— I 



MNEM 


S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


i 

1 

1 

! 

I 

1 

t 


PP 

t 


M 




Place/ 

Publisher 


30C 


<Place, Place, etc.^ ; 
^ Publisher^ 


PR 


s 




Total 

Estimated 

Price 


22 


^Estimated Price (total price to be ' 
printed on Purchase Order 


PRE 


S 




Pre-catalog 

ing 

Indicator 


10 


1 Pre-cataloged 

2 Copied from MARC; date 


PR I 


s 




Post Receip 
Priority 


t 1 


1 Urgent (highest priority) 

2 Rush 

3* Current Interest 

4 Research Interest (lowest priority) 

5 Deferred 


PRO 


s 


— • 


Type of 
Procurement 


2 


po Regular Purchase Order 
pp Prepayment P.0, 
pd Deposit Account P.0, 
s Standing Order 

a Approval 
b Blanket 
g Gift 
e Exchange 

x Inactive file material (e.g. in prin 

or out-or-print desiderata) 
y All other 


PUX 


s 




Additional 

Acquisition 

Information 


60 


' 


» # 

RAD 


s 




Requestor 
Address or 
Depar tment 


60 


^.Street or Dept ^ ; 
^City, State^> 




r->“ 
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o 

ERIC 



MNEM 


S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


RECj 


S 




Type of 
Record 


2 


<1-2 Character Code^ 


RID 


a 




Requestor 
Identifica- 
tion Number 


3 


i 

1 

i 


RN 


s 




Requestor 

Name 


60 


« 


RNI 


s 




Requestor 
Notif icatioi 
Indicator 


1 

i 


1 Send Notice upon receipt of material 

2 Send Notice upon completion of 
processing 


RT 

J 

i 


s 


* 


Remainder 
of Title 
Statement 


200 


Note: 1. Used to code all data after 

subtitle and before edition 
statement. \ 

\ 


SBN 


M 




Standard 
Book Number 


16 


* 


SD* 


S 




Subscriptio 

Date 


l 10 


Changes New attribute 


SEA* 


M 




Series Entr 

Personal 

Author 


r 200 


Change: New attribute 


SHE 

* 


K 




Shelving 

Location 


30 


<Locatior^; 

f Bibliographic Descriptor Information*} 
^Number of Copies S 

Note: 1. If bibliographic descriptor 

information equals that in 
ORD. leave blank in SHE. 
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o 

ERIC 



MNEM 


S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


SI 

\ 




S 


Searcher's- 

Initials 


3 


^3 Character Code^ 


SIZ 




S 


Size 


10 




SEI* 


M 




Series 
Added Entry 


240 


Note: 1# Use SEA to code series entry 

Personal Name 

Change: from S/K^S to S/M*M 


SPO 


S 




Special 

Acquisition 

Series 

Information 


240 


/ 


ss 


M 




Subject 

Heading 


100 


Note: !• Use SUA to code Subject ' 

Personal Name# 

i 


* 

SSA 


H 




Series 

Personal 

Author 


200 


Change: New attribute 


SSI 


M 




Series 

Statement 


240 


Note: 1# Use SSA to code Series 

Personal Name# 


•STA 

| 


M 




Material 

Process 

Control 


70 


< Location, Date^ ; 

LC Awaiting Library of Congress 
Information 

MA Awaiting Information from MARC 
CD Catalog Division 
EB End Processing Department 
Cl Circulation Division 
0 Other 

^Bibliographic Descriptor Information} 
^Number of Copies J 
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MNEM 


S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


STA 

% 


■ con 


:inued 






Notes 1. Leave bibliographic descrip- 
tor information sub-element 
blank if all elements equal 
elements of 0RD* 


* 

SUA 


M 




Subject 

Personal 

Author 


200 


Change: New attribute 


T 


s 


TW 


Title 


300 


^Short Titled <■ 

<Sub-TitIe> 


TA 


M 


TW 


Added Title 


240 


<£short Titled 
<Sub-TitIe> * 


TI* 

1 


s 

f 




Tracing 

Indicator 


40 


^Attribute mnemonic^ 

^Element number^ 

Change: From M\X«100 to MAX*40 


TR 11 


s 




Translation 


13 


1< Language of the text^ 

2<^Language from which the text was 
translated^ 

3^0riginal language if different from 
the language from which text was 
translated^ ' 

4^Language(s) of summaries^ 

Note: 1, For example: leng2fre 


TOO* 


M 




Title — 
Romanized 


30C 


Change: New attribute 


TU* 


H 


TW 


Uniform 

Style 


I2C 


Change: From S/McS to S/M«M 



^For Language codes, see "MARC Language Codes" , prepared by 
Library of Congress, Information Systems Office, 1968. 
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MNEM 


S/'M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 

CONTENT 


TYP 

t 


S 




Type of 
Work 


2 


f Festschrift 
z Fiction 
b Biography 
d Dissertation, thesis 


VAD 


S 




Vendor 

Address 


60 




VCT 


S 




Vendor 

Catalog 

Information 


40 


^Catalog Name or Number^ ; 
tern Number 

Note: 1. For example: VCT*; 4/68-02U 

or VCT 200 


VID 


S 




Vendor 
Identifica- 
tion Number 


5 


« 

^5 Digit Code^ 


VN 


s 




Vendor Name 


60 




* 

VSP 


M 




Message to 
Vendor 


75 


Notes 1* For example: Rush, Please 

Bind. 5t;h ed. dnly, Autor 
graphed Copy only, etc. 

Change: From S/M - S to S/M*M 


XOR 


s 




Type ©f 
Order 


3 




XT 

t 

1 


s 


« 


Incomplete 

Record 


1 


1 Diacritical marks not included 

2 Incomplete record (specified by MARC] 


! 

XX 

0 


M 




Notificatic 
Name and 
Address 


n 24( 


> <Name> $ 

^Street Address or Dept. Name^J 
<plty, State Zip^ 
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MNEM 


S/M 


INDEX 


NAME 


MAX 

LTH 


CODES/FORMAT 
CONTENT • 


XX - 
1 


:onti 

• 


ltied - 
*■ 


% 

■ # 

• 




f 

Note: 1* To be used when requestor 

notification to be sent to 
* person other than requestor, 
2, An address with two sub-' 

elements will be assumed to b 
Stanford ..University, Inter- 
departmental Mail, 

' ! 

i 

• • * i 

* • 1 
„ t 

1 

i 

' . ' • •• X i 

\ 

t 1 

. W 

* X 1 
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i 1 
! 1 
! 1 
i l 
> 




! . * . 
i 

APPENDIX I 


# # # 






Indexes 




File 


Index 


Name 


Contents 


IPF/MARC 


PM 


Personal Name 
Index 


Name indexed to second 
comma in PN. Attributes 
indexed in PN are: 

. A, AE | AA. 


IPF/MARC 


CN 


Corporate Name 
Index 


Attributes indexed are* 
CA, CAE, CAV. 


IPF/MARC 


CF 


Conference Name 
Index 


Attributes indexed are: 
CF, CFE, CFA, 


IPF/MARC 


TW 


Title Word Index 


Attributes indexed are: 
TU, T, TA. 


IPF 


• ID 


Identification 
Number Index 


Attributes Indexed: ID. 


IPF/MARC 


D 


Date Portion of 
PN, CN, CF, TW 


Attribute indexed: D. 






Indexes* 




MARC 


M 


LC Card Number 


Attribute > indexed : CRD* 
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APPENDIX II 



Attribute ADD: Ship to Addresses 

Address Condition 



Order Department 

Stanford University Libraries 

Stanford, Calif. 94305 

Serial Department 

Stanford University Libraries 

Stanford, Calif. 94305 

Current Periodicals Desk 
Stanford University Libraries 
Stanford, Calif. 94305 

Meyer Undergraduate Library 
Stanford University Libraries 
Stanford, Calif. 94305 

Lane Medical Library 
Stanford Univ. Medical Center 
Stanford, Calif. 94305 

Humanities and Social 
Science Reference 
Stanford University Libraries 
Stanford, Calif. 94305 

Library 

Food Research Institute 
Stanford University 
Stanford, Calif. 94305 

Library 

Food Research Institute 
Stanford University 
Stanford, Calif. 94305 



Material and invoice to 
same location 



Material and invoice to 
same location. 



Material to this location; 
invoice to Order Department. 



Material to this location; 
invoice to Order Department. 



Material and invoice to 
same location. 



Material and invoice to 
same location. 



Material and invoice to 
same location. 



Material to this location; 
invoice to. Order Department. 
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Attribute ADD; Ship to Addresses 



Code 

9 



10 



11 



12 



13 



14 



15 




Address Condition 

Director Material to this location; 

Stanford in Germany invoice to Order Department. 

Landgut Burg 

7056 Beutelsbach bei Stuttgart 
GERMANY 

Director 

Stanford in Italy 
Villa S. Paolo 
Via della Piazzola, 43 
Firenze, ITALY 

Director Material to this location; 

Stanford in Austria invoice to Order Department. 

Seilerstatte 30 
1010 Vienna 
AUSTRIA 



Material to this location; 
invoice to Order Department. 



Director 

Stanford in Britain 
Harlaxton Manor 
Grantham, Lincolnshire 
ENGLAND 

Director 

Stanford in France 
1, Place Anatole-France 
Tours, Indre et Loire 
FRANCE 

Library 

Mr. Alan Baldridge 
Hopkins Marine Station 
Pacific Grove, Calif. 93950 



Material to this location; 
invoice to Order Department. 



lu: 

Material to this location; 
invoice to Order Department. 



Material to this location; 
Invoice to Order Department. 



Document Division Material and invoice to 

Stanford University Libraries same location. 

Stanford, Calif* 94305 

(Individual requestor^ name Material to this location; 
and address) invoice to Order Department. 



O 

ERIC 



250 



283 



APPENDIX III 



Author-Title Entries 

In the case of an author-title entry, the title will be coded and input 
as a sub-element of the author attribute. 

With the present indox construction, a title coded as part of a personal 
name will not be indexed whereas a title as part of a corporate or 
conference name will be included as index words in thei corporate name 
index and conference name index, respectively* Therefore, at the present 
time, if the title portion of an author- title entry is significant and is 
not coded elsewhere as T or TA, it should be coded as TA and input. The 
title so coded as TA will be indexed in the title word index. 



O 

ERIC 
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LIBRARY SYSTEM NOTES 



Number 


Title : 


i . 


Project Assignments 


2 


Continuous Testing 


2a 


MARC Conversion 


3 


MARC Conversion 


4 


Attribute List 


5 


Survey 


6 


Exclusion List 


* 7 


Diacritics 


8 


P.0. Output Spec. 


9 


Short Form Output 


10 


Science Approval 


11 


Interface 


12 


IPF Building Alternatives 


13 


Schedule 


14 


Checklist of Requirements 


1.5 


File Organization 


16 


Flow Charting Techniques 


16 rev.l 


Flow Charting Techniques 


17 


Program Specifications for Acq. 
Purchase Order Printing 


18 


Claim and Cancellation Notice 
Program Specifications 


19 ./ 


Schedule of Activities for Acq. 
and Biblio. Coding Ed. 


20 . 


Bibliographic Coding Procedures 


21 


File Organization 


22 


Sample Search Argument 


23 


MARC Conversion 


24 ' 


MARC Conversion 


25 


MARC Conversion 


26 


Data Control 


27 


Update to Spec, for Acq/ P.0. Printing 


28 


Data Control 


29 


Meyer/Main Library Circ. System Requirements 


30 


Circulation System 


"31 


Report Prep. Schedules 


32 


Comparative Acq. Statistics 


33 


Report Generations and Statistics 
Gathering: A Problem Definition 


34 


Circulation System 


35 


MARC Conversion 


35 Rev. 1 


MARC Conversion * V. 


35a 


Circulation System 


36 


On-Line Input . - . 


37 


. On-Line Input 


,38 


System Diagnostics 


39 


Attribute List Update * 


40 


SPIRES Reference Index 


A1 _r 


KARC Conversion 


ERLC 


Data Base Building specs* 




i j . 
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Date 

10/14/68 

10/22/68 

11/31/68 

10/22/68 

2/24/69 

12/17/68 

1/17/68 

2/7/69 

1/9/69 

1/9/69 

2/20/69 

2/19/69 

12/3/68 

1/24/69 

1/24/69 

3/3/69 

3/5/69 

10/22/69 

1/9/69 

3/11/69 

3/12/69 

3/17/69 
3/17/69 
3/17/69 
10/24/68 
10/31/68 
11/12/68 
3/26/69 
4/9/69 
2/27/69 
3/15/69 * 
4/21/69 ' 
4/29/69 
5/2/69 
5/5/69 

4/5/69 

5/14/69 

6/5/69 

5/7/69 

5/19/69 

5/23/69 

5/23/69 

6/2/69 

6/6/69 

6/16/69 

6/12/69 
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LIBRARY SYSTEM NOTES 



Number 


. i 

Title ! 


63 


Plans <£ tSchedules 


A3 rev. 1 


Plans & Schedules 


66 


Plans & Schedules 


65 


Plans <£ Schedules 


66 


Short form update 


67 


Organization Chart 


67a 


Special Character Handling 


68 


Check Digit Algorithm 


69 


Special Charac. &. Diacritical Marks 


50 item 1,2,3,6. 


Data Preparation conting. 


51 items 1-7 • 


MARC Coversion Spec. Updates 


52 


Gat- Design Study 


53 


Voucher printing &. claim generation 


56 




55 


Requestor file proposal 


56 


Requestor notice printing specs - 


57 


Use of MARC 


58 


On-Line input: a cost analysis 


59 


On-Line Searching 


60 


DC & DP Statistics 


61 


Program Spec, for NPAC Notice Printing 


61a 


Cost of including Subject Heading, LC 
Class Number & Series Statement Indexes 




to the local MARC Data Base 


62 


Types of System Documentation 


63 


Cost of MARC Indexes 


66 


Procedure Manual 


65 


Catalog Card Production Feasibility Study 
Final Report 


66 


Operating cost under SPIRES 


IT? • 





r 







Date 

6/12/69 

7/29/69 

6/13/69 

6/13/69 

6/17/69 

6/17/69 

7/7/69 

6/17/69 

7/10/69 

7/25/68 

9/2/69 

7/25/69 

7/28/69 

missing 11/17/69 

8/11/69 

8/21/69 

8/69 

9/2/69 

9/26/69 

10/9/69 

10/17/69 

10/26/69 



10/22/69 

10/26/69 

10/22/69 

10/23/69 

10/28/69 
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Project BALLOTS 

Subject: Acquisition System Design 

Library System Note: • No* 18 
Name: Jerry West 

Date: March ll y 1969 

Title: Claim and Cancellation Notice Program 

Specifications 
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Purchase Order Program Specification for Printing Cancellation Notices 



A‘. General Rules 

1, The Cancellation Notices should be printed using the same specifica- 
tions as fox P.0. printing except as noted below in C. 

2. The Cancellation Notices should be grouped together following the 
P.O.’s, in sequence by Vendor number. 

B« Attributes 

The following list of attributes will be printed on the Cancellation 
Notice; 

1. The Order Number (ID) 

2. Date of Order (FD) 

3. Price (PR) 

4. Vendor Number (VID) 

5. Main Entry (ME) or Head of P.0, indicator (PME) 

6. Title (T) (If ME or PME don’t point to T ; TA, or TU) 

7. Edition Statement (ED) 

8 # Place/Publisher (PP) 

9. Bibliographic Descriptor from CAN or ORD. If the descriptor in 
CAN=-S then use the descriptor from ORD; else use the descriptor 
in CAN. 

C. Detail specifications and exceptions to general rule A-l above. 

(Refer to P.0, specs and form layout.) 

1. Print cover sheet with vendor address as per P.0, specs. 

2. Name of form (area #1 in form layout). Print ” CANCELLATION 
NOTICE” on line 1 and line 3. (centered) 

3. Date of Order (area #2). Print as per P.0, specs. 

4. Order Number (area #3). Print as per P.0, specs. 

5. Ship to and billing information (area #5) Om.it. 

.6. Total Est. Price (area #6). Print as per P.0, specs. 

7. Vendor Number (area #7). Print as per P.0, specs. 

8. Number of Copies (area #8). Print as per P.0. specs. This infor- 
mation will be in the bibliographic descriptor in either CAN or 
ORD. (see B-9 above) 

9. Bibliographic Information (area #4). Print only ME or PK3, T, 

(if PME or ME don’t point to T, TA, or TU), ED, PP, and biblio- 

graphic descriptor (from CAN or ORD. See b-9 above) 

10. Cancellation Message (use area Y^5) 
line 12; ’’***PLEASE NOTE***” 
line 13; blank 

line 14-?; ” PLEASE . CANCEL THE ORDER INDICATED ABOVE’’ 
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Data Base Building Specifications 
For Extracting Cancellation Output 

When attribute CAN (cancellation information) is input, check "Type of 
Cancellation” in the attribute. 

If Types D then no cancellation transaction is needed. 

If Type =: R or L then create the cancellation transaction. 



The cancellation transaction should have some indicator signifying that 
this is a cancellation record. The presence of the CAN attribute i i no 
indication since CAN is merely a history of cancellations for this record, 
A possible indicator would be to set PROsa”canc” in the cancellation 
transaction only. S 



If the input transaction also contains attribute PRO and PROsc ”P0" then 
a further step is necessary: 

Create a purchase order transaction from the update^ record using 
the P.0, generating specifications after all update 
have been made. The fact that PRO 2 = ”P0” should indl 
printing program that this is a P.0, transaction ev 
attribute is present. 

This step is necessary to do such things as cancel an otjder from one 
vendor and re-issue the order to another vendor. 



to the entry 
cate to the 
n though the CAN 




O 
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Purchase Order Program Specifications for Printing Claim Notices 



A. General Rules 

1. The Claim Notices should be grouped together following the Cancellation 
Notices, in sequence by vendor number. 

2. The Claim Notices should be printed using the same specifications as 
for P* 0. printing except as noted below in C. 

B. Attributes 

1. All attributes which are to be printed on the P. 0. should be printed on 
the Claim Notices. 

2. The bibliographic descriptor information will be taken from CLD or ORD. 

If the descriptor in CLD = S then use the descriptor in ORD; else 
use the descriptor in CLD. 

C. Detail specifications and exceptions to general rule A-l above, 

(Refer to P. 0. specs and form layout.) 

1. Print cover sheet with vendor address as per P. 0. specs. 

2. Name of form (area number 1 in form layout.) 

Check Claim Date attribute (CLD). 

a) If object of claim in CLD equals f, M ,f then print "CLAIM NOTICE" 
on line 1. (centered) 

b) If object of claim in CLD equals "I" then print. "CLAIM FOR INVOICE" 
on line 1. (centered) 

c) In both a) and b) above, print "Dealer Report" on line 3, 

3. Date of order (area number 2) same as P. 0. specs. 

4. Order Number (area number 3) same as P, 0. specs. 

5. Ship to and billing information {area number 5) same as P. 0. specs. 

6. Total estimated price (area number 6) same as P. 0, specs. 

7. Vendor Number (area number 7) same as P. 0. specs. 

8. Number of Copies (area number 8) — This information will be in the bibliographic 
descriptor in either the CLD or ORD attributes (See B-2 above.) 

9. Bibliographic Information, messages, etc. (area number 4) same as P. 0. 
specs except bibliographic descriptor will he taken from either CLD or ORD 
(see B-2 above.) 
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Data Base Building Specifications for Extracting Claim Output 



The method of creating Claim Notice transactions described below will 
only be used until a complete update program and a claim date index have 
been implemented. 

When the attribute CLD is input then a claim transaction will be created. 
The trai ^action should have some indicator signifying that it is a claim. One 
method would be to set PRO = M CLAIM” in the claim transaction only. 

Before the claim transaction is created the data base entry should be 
updated. The input CLD attribute should replace any existing CLD attribute 
in the data base, and be added to the CLA attribute. 



i 

i 

i 

i 

i 

( 
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COMPUTER NOTES INDEX 



N o. 




Author 


Comments 








Date 


i. 


Information Retrieval in High Energy 
Physics 


Parker 


Original SPIRES 


Prop. . 


12/1/66 


2. 


Input Forman and Character Set Speci- 
fications for SLAC Preprint Collection 
C or.sp *o ter Re Ccrence Re t r i ova 1 i. I a 


Parker 


. Superseded 


by 


# 


30 


9/66 


3. 


Draft Specifications for High Energy 
Physics Reference Retrieval System 


... 


See also # 


26 






1/31/67 


4. 


Search System 


JEG 


Superseded 


by 


#25 &27 


1/26/67 


5. 


SC AH — A Free Field Read Program 


JEG 


Superseded 


by 


# 


25 


2/1/67 


6. 


File Structure Description 




Superseded 


by 


# 


20 




7. 


Attribute List 




Superseded 


by 


# 


37 




S. 


Physics Retrieval System 


Mar she ck 


Superseded 


by 


# 


20 


5/8/67 


9. 


Physics Retrieval System 


Mar shock 


Superseded 


by 


# 


20 


5/2/67 


10.' 


Attribute List 












7/11/67 


i 

.1.! 


Interim Character Set 


Parker 










7/19/67 


2. , 


Card Input Format (SLAC Preprints) 


Parker 


Superseded 


by 


# 


30 


7/27/67 


13. ' 


Sample Slock in Data Base 


Parker 


Superseded 


by 


# 


20 


8/1/67 


4. 


Sample Block in Author Index 


Parker 


Superseded 


by 


# 


20 


8/4/67 


15. 


Card Input Format (SLAC Preprints) 


Parker 


Superseded 


by 


# 


30 


8/4/67 


.6 . 


Revision of Data Base Format 


Parker 


Superseded 


by 


# 


20 


8/10/67 


7. 


Revision of Index • 


Parker 


Superseded 


by 


# 


20 


8/11/67 


IS. 


Revisions to SLAC Preprints Input 
Format 


Parker 


Superseded 


by 


# 30 


8/11/67 


i9. 


Preliminary File Constructing Program 


JG 


Obsolete 








8/14/67 


0. 


Final Version of Data Base and Index 
Formats 


JG & Parker 










8/15/67 


1. 


Interim Data Base Output Format 


Parker 










8/21/67 


22. 


Suggested Algorithm for Name-Matching 


Parker 


Superseded 


by 


# 


31 


9/6/67 


3. Revisions to Card Input Format, SLAC 

^ Preprints 

ERIC 


Parker 

259 


Superseded 


by 


# 


30 9/21/67 

292 



292 



2 



! 




Author 


Comments 


Date 


A. 


Proposed Algorithm for Date Conversion 


Parker 


Superseded by '# 29 


9/27/68 


25. 


SARSPIS: Syntax Analyzer, Recognizer, 

Parser and Semantic Interpretation 
System 


JEG 


See also # 33 634 


9/29/67 


( . 
1 


Draft Specifications for an Inform. 
Retrieval S y s tern 


Parker 




10/2/67 


27. 


The SPIRES Scope Demonstration System 


JG 




10/3/67 


S. 


Specifications for Statistics Records 
in Index Piles 


Parker 


Obsolete 


10/3/67 


9. 


Revised Date Conversion Algorithm 


JEG 




11/27/67 


I*°- 


Input Format for SLAC Preprints 


LA 




11/28/67 


jl. 


Name Hatching Algorithm 


Parker & JG 




12/6/67 


2. 

1 


Attribute List and Descriptions 




Superseded by # 37 


3/29/68 


33. 

1 


Modifications to SARSPIS 


JEG 




4/23/68 


I 4. 


Changes in SARSPIS Free Field Scanning 
Procedure LOOK 


JEG 




5/15/68 


i 

I 5- 


Storing Statistics Concurrent with 
Updating and Making Use of Them 


Caton 




6/20/68 


6 . 

1 






Superseded 




! 7 i 


Revised Attribute Descriptor Table 


KM 


Superseded by #47 


6/25/68 


38.1 

l ^ 


Preliminary Specifications for the 
BALLOTS /SPIRES Update Program 


Burwell 




6/25/68 


39. : 


Language Specifications (Update Program) 


Parker 6 Burwell 


7/3/68 


1 0. 


Specification of a Supervisor for 
the Interactive Operation of SPIRES 


Riddle 




7/9/68 


x • 


Data Management and Overnight Requests 


Mar she ck 




7/11/68 


42. 


Translation of DESY Tapes 


Clark 


■ 


7/18/68 


3. 


File Directory 


Marsheck 




8/68 


44. 


Optimization and Recovery for Data Base 
and Index Building Programs 


Clark 




8/15/68 


45. 


On-Line Job Initialization Program 
Requirements (JIP) 


Burwell 




8/15/68 


46. 

ERIC 


Data Base Block Extensions 


Marsheck 

260 
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undated 



3 



No. Author Comments 

47. Attribute List and Descriptions Alpha- Addis 

betized by Abbreviation 



O 



ERIC 

hfliflaffHHaaaa 
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Date 

4/21/6 
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COMPUTER NOTE #38 






O&TXCiSS 






7 * , * ;• ; ■ : ■ •. • 17 

J t> X w\*L* v#v> 



gdkes 



i 

1 






Ti ' * c' S 
JJ v » * «* *.* .1 1 . ~;.\V 



O 
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table a? ccreggars 



Page 



X. OVERVIEW X 

SI. FILE CONTROL 2 

m. USER ei^irgessiss: jiscksehakce a*d lcadux: 2 

IV. IlimALIZKJG 3 

V. SCAEHSKS AX© CO&3PSESSHS INPUT 3 

VI. SSEEAX AKO ELSISBiT CSHCE3HG A 

VII. IEDEX AND DB BLOCS SEARCH 5 

TCI. LOGICAL RECORD KW D3 CLOCK BUILDING AND M&IK2SHASI0E 5 

IX. ‘ IISES EltITIIvG, BDILDIliG, AHJ> MAIH3SBAECE 6 

X. FINAL MAKE-UP 7 

XI. UPDATE SYK2AX COarVKJTIOSS 7 

XII. FIGURATIVE UPDATE UCKDS 7 

XIII. UPDATE STATESEXJTS DESOSXPTXCiJ 7 

XIV. UPDATE STATEISHTS 8 

XV. MISCELLANEOUS FEATURES 9 

XVI. THINGS UNDONE 10 
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I 



WSEI7IEW 



The Update program will be organized into Che following sections. 



1 . executive 

2. conmunicaMon area static storage 

3. system utilities 



4 * applies ti on program*; 



S3 fils control 

iic user er.v 1 r ovr&er* >; loading and maintenance 
iii, S3 ir?.5 tie lis? tiers 
iv . transaction processing 
v. index aud block searching 
vi * logical record <:i&d E-;5 block processing 
vii. i nd$>: accessing 
viii. update termination 



A. EXECUTIVE SESSZOff 

7?he executive directs control between each of the application pro- 
grams and allocates and releasee dynamic storage* Ifader the single- 
user batch system, all application programs are ensured to be 
resident. Under the on-line system 5 the executive v. T ili parcel 
ays ten resources to each user and load each application program 
and its eavi r ccaian t • 



B. CCSS51HS:CASI0?c £B3XZ<B 



All interface variables end any static storage viii be grouped 
together into a cocnon section. All section <md application program 
interfaces will be handled by the cejaaunica tiers section.. 

Long paraxaetsr lists are inefficient and needless. If necessary , 
parameter blanks will be built and a single parameter will bo used 
to reference the block. 



C. OSSai UTILITIES 

These are subroutines which are used oftsn by many application 
programs, Again* these subroutines are identified mostly for 
. the £ orfclicoming on-line systacu Slav- is, these subroutines 
are required sufficiently often to stake them permanently resident . 

d. APSuicArdca :?&a sum 

These are 03 task-specific ar.d are structured. 3hafc is r . the lower 
the levels tho narrower the tusk scope. A doocriptioc of each 
application lyjosrram follows* 
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IX. FILS CO^SSCS. 

Opens, closes, end sets the usage of all files depending upon 
the function to be performed. Under the slcgle-user batch system, 
this section will be smell and simple. However, under the 
multiple-user on-line system, each user will have a separate 

section. 



III. USEE ENVEiGSKEEE WJSEEama AND LOADING 



A user environment will include the following. 

1. Attribute Name and Other Iiiouuo 

2. Attribute Name Abbreviations 

3. Attribute Value Kind, e.g. alpha 

4. Attribute Element Multiplicity 

5. Association Group Definition 

6. Element Editing 

a. maximum bytes per element 

b. kind checks 

1. integer 

ii. address 

iii. coded 

iv. alpha 

v. other 

7. Physical Record Specifications 

8 . Update Commands and Other Verbs 

9. ’'Piece Pairing" Syntax Checks 

10. Update Action Array 

a. Command - Attribute Array 

b. Chain Algorithm table 

11. Index Editing 

a. change characters to upper case 

b. eliminate selective special characters 

c. word editing 
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i. 3-lettar words 
ii. Inclusion List 
iii. Exclusion List 
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d. eliminate surname prefixes 

e. eliminate extra blanks 

The collection of tables defining a user environment will be grouped 
into a separate file and be updated by sequence number. 



H. INITIALIZING 

Initialisation will include 

1. index blocks 

2. DB blocks 

3. loop variables 



V, SCANNING AND CCHEKBSSXRG 11V2VZ 

Scanning is defined as extracting key words, nouns, verbs, pre~ 
positions, and elements from an input buffer of update transactions, 
'ibis input buffer will be called the physical transactions blocks 
(KB) . 

Compressing means eliminating delimiters, quotes and blanks, and . 
extra blanks including leading and trailing blanks within a value. 
She resultant output of scanning and compressing will be called 
the logical transaction blocks (LTB) . 



An entry in the LIB would look like: 
> > — 



where: 

EC 

CC 

CS 



EC 



EF 



CC 



CS 



0 



» keyword 
«* keyword value 



» entry code 
•» character count 
» character string 
* error flag, to be set by editing 



^Eliminate the second and following blacks within a value. 
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VI. SYNTAX AND ELEMENT CHECKING 

A. Syntax Checking 

Syntax checking will use a "Piece Pairing" Table (cf. Jim 
Harcheck ' s parsing lecture notes dated G/18/6S). A "piece" 
in this context is update nouns, verbs, prepositions, and 
elements . 

There will be 3 possible results in syntax checking: 

i. sequence legal, continue with sane logical record 
ii. sequence legal, last piece for this logical record 
• iii. sequence illegal 

Tills means & Piece Pairing Table will consist cf sub-tables 
to correspond to i. end ii. above. Of course only the elemeat-XD 
sequence (see Update Statements section) would cause action ii. 
But a special set of user-specific commands might also. 

B. Element Checking, 

Element checking will include: 

1. maximum number of bytes per elecsent per attribute 

2. attribute kind checks 



kind 


checks 


i . integer ) 


high, low 
limit checks 


ii. address J 




iii • coded \ 


discrete values 


iv. alpha ) 




v. other 


special checks 



There will be 4 levels of error messages and resulting actions. 

1. catastrophe, skin to next ID piece, don’t update this 
logical record. 

2. error, skip to next attribute, don't update this attribute. 

3. error, continue scan, don't use this element. 

4. warning, continue scan, use this element. 

All errors will be reflected in the ITS error flag. 



-5- 




VII* UMZ AND D3 BLOCK SSAECB- 

la addition to index blocks and D3 blocks, I would like to 
propose adding an index-index (IK3.X) . An I22X would contain XX 
block numbers corresponding to a given hash code. An IX block 
would be structured essentially as is currently documented. 1XXX 
would be assigned block 0 of the index file and look like this: 



IXIX#1 


2X#1 , 1 


9 C 9 -1 

* 


7XD£#2 


I Xv 2 , 1 




Suppose a logical record is to be added to an existing file. The 
following actions would take plrce. 

1. Logical record 2D # would be hashed yielding an 1X12$ 

2. I XXX' numbers would be ordered oonotonically increasing. I X XX 
entry position would be calculated (regula falsi} . 

3. Each index block in the XXIX entry would be searched looking 
for a match on "SEX" , noting the block with the greatest 
unused space beyond a given threshold. 

4. In thi6 example there would be no watch on "key". Heuce a 
B3 entry wouid be added as well as an initial index entry to 
the index block with the greatest unused space. If no 
available index block existed, a new index bit ik would be 
started and its number added to the XXIX entry. 

5. If adding a secondary entry to an .Index block causes overflow, 
an Initial entry and its secondary entries will be moved to 
another or new index block. 

As a consequence, 2 desirable results would occur: 

1. no overflow index blocks 

2. secondary entries will be in the sens block as the initial entry. 



VIZI. LCSICAL SECQSD AND SB BLOCK BUILDING AND E&1NZENAHCE 

The structure of a Lb block will remain essentially as is currently 
documented. 




Transactions against a given logical record will be processed as a unit, 
i.e. edited, syntax checked, etc. 



Entry transactions will be matched against logical record entries 
Culetfceatn} eivl ska iralased ‘£S bicuk will result as is dana in the 
.Phase I 1-rii-L-Ji. 
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An Update Action Array will be part of the user's environment. This 
will consist of a 2 dimensional array of attribute positions vs. 
update command position -- position vjithin the environmental tables. 
Each entry would contain an algorithm chain number. An action chain 
V70uld have a series of action numbers. 

Pictorially, the relationship is following 

COifilAIID-ATTRIBUKJ AR2AY 

attribute position 




Statistical algorithms and citation processing would merely be a 
subset . 



IS. IMBEX EDHIKS, BUXLBIKS, AMD MAINTENANCE 

There will be an Index Editing Table (1ST) for each user consisting 
of attribute vs. editing algorithms. The following current editing 
algorithms will be retained. 




1. CAES 

2. CMIEBSS 

3. SFECCOT 

4. CABSGIJT 



5 . 
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(i. NAJBYL 



XI. 



XII. 



mi. 



o 

ERJC 



Inclusion and exclusion lists will be user- specific. 



PZHAL WRAP-UP 

This is essentially the same as the EftDRUIJ procedure of PPIHKJT. 

Th3t is, it x^ill: 

1. write the last D3 and index blocks. 

2. call the Pile Control section to close the remaining open 
files. 

BFiiASE SVmi CCS7ERT2C2TS 

1. Braces, ? ] , mean a choice is required. 

2. Brackets, [ ], mean the clause is optional, 

3. Underlining means the clause is repeatable. 

4. Words printed are literal and keywords. 

5. Words written are figurative. 

vihvsf’zrm update words 

1. Entry-id: logical record identification 

2. Update-action: create, add, delete, replace, change 

3. Attribute-descriptions includes attribute and attribute-value 

4. Attribute-values the collective set of attribute elements 

5. Attribute elements a single value within an attribute, e.g. 
A3JT1U31 *» "ZRCWM, S«Ec h . Author is an attribute, Brown, S.E. 
an csleinent. 

UI3ATE STATE5B2KTS EBSCR1PT1CK 
A. 703. Clause 

The FOR clause defines an association group, i.e. assigns 
a set number. In addition, it allots indirect specif! cations 
of an element. For estample, delete a title vhwe author 
is S.E. Erovn. The title vith the earns sat number as the 
author would be deleted. 
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ft. DELE® Command 

1* DELE ® ALLs delete a logical record 

2. DELETE ALL attributes: delete an entire attribute 

3. DELETE attribute (att-ccuat)* delete the atfc-coimfc 
occurrence of the attribute 

G. EE£LAG3 Cocimand 

Deplace an entire attribute element defined by attrihute- 
daseripfciou-l to the value specified by at tri Jute-value. 

D, AL'ZEIt Command 

Alter the portions cf the attribute clement defined by 
attribute-dcacription-l to the value specified by attribute- 
value, 

XXV, UPDATE STMTJffiOTS 

General forn for cresting, adding, or deleting DB entries or elements^ 
ID 1 entry- id : update -action a fctribu t e-descri p t ion- 1 

[l y GR at tr ib ut e - d gj s c ?: ip 1 1 on- 2] 



k. 



Create a DB entry or add D3 elements to an existing entry 




attribute *att-val-l* 



[FOE attribute ’att-val-2 1 ] 



B. Delete a DB entry or DB elements 

1. DELETE ALL 

2. DELE/31 [ALL] attribute [ett-val-1] [FOR attribute “att-val-2’] 

3. D’luETE attribute [ 'att-val ' ] [(att-count) ] 

Attribute count means occurrence — an attribute entry or the 
occurrence of an attribute with a given value. 
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General form for replacing or changing DB entries or elements: 

attrlbutc-descrlption-1 [ Z WITH ) at tribute -value] 



( AT •721' ^ ( 10 ) 

^ \ 6ttrl bu te~ descrip tio n»l [ t W ITH ) att ribute -- 






[ FOR attributo-description-2 ] 



C. 



Replace entire D3 entries or replace or change 33 elements 

1. KEELAGE ALL WISH attribute 'att-val ’ 

2 • C ALTER ^ ^ 

} KEELAGE ^ [ALL] attribute [ ‘ att-val- 1’ ] ( WISH } 'att-val-2* 

[FC&. attribute ’att-val-3] 

3. C ALTER ) 

£ EEX-LAGIi *} attribute ( ‘att-val-l * ] [ (att-count) ] 



( to ) 

(_ WITH 3 



‘att-val-2* 



2S? 0 1-IIS-3ELLAHECJJS FEATURES 

A. Delete /replace attribute value qualification 



The attribute value to be deleted or replaced could be partially 
but uniquely specified. For example consider the following 
attribute entries. 

1. Leave thi3 one alone. 

2. Remove this one. 



3. Hot this one. 



A transaction 
DELBIE attribute 'REHG7E' 
makes number 2 unique. 
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m. SHIBBS UHDC&ffi 

1. Storage Requirements 

a. Static 

* b. dynamic 

c. Program 

2. Definition Conrnunication Section 

3 . Manpower Requirements 

a. Detail Specifications 

b. CocUng 

c. Checkout and Integration 

d. Docmftentatioa 
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i STANFORD UNIVERSITY LIBRARIES 

PROJECT BALLOTS 



.Study of Present Acquisition 
System 



By 

Diana D. DeLanoy 
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• TABLE OF CONTENTS 
ACQUISITION CURRENT SYSTEM 



I. Introduction and Organization Chart 

II* Order Department 

A. Introduction and Evaluation 
B* Flow Charts and Procedures 

1. request and purchase order generation 

2. overseas ordering 

3. PW and BNB ordering 

4. receiving 

5. bookkeeping 

6. cancellation 

7. out of print 

8. search and establish 

C . Forms 

1. input 2001 - 2099 

2. output 3001 - 3099 

D. Files 4001 - 4099 

E. Miscellaneous 

III. Government Documents Division 

A. Introduction and Evaluation 

B. Flow Charts and Procedures 

1. request and ordering 

2. receiving 

C. Forms 

. 1. input 2101 - 2199 
2. output 3101 - 3199 

D. Files 4101 - 4199 

IV . Exchange 

A. Introduction and Evaluation 

B. Flow Charts and Procedures 

1. incoming processing 

2. outgoing processing ■ . 

C. Forms 

1. input 2201 -2299 

2. output 3201 - 3299'--.., 



D. Files 



4201 - 4299 




\ 



V. Gift 

* A. Introduction and Evaluation 



* A. 
B. 



B. Flow Charts and Procedures 

1. gift receipt processing 

2. memorial fund acquisition process 



C. Forms 

1. input 2301 - 2399 

2. output 3301 - 3399 



D. Files 4301 - 4399 
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VI. Resources Development 

A. Discussion 

B. Form Examples 

VII. Miscellaneous 

NOTE - Although Binding and Finishing is a part of the Acquisition 
Division, functionally it belongs more with Serials and will 
be covered at a later date. 
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Input Doc, 
Output Doc 



ORDER DEPARTMENT 
ORGANIZATION 



DOCUMENT INVENTORY 



No. 


Document Name 


Source 


Destination *« 


Peak 

Volume 


Average 

Volume 


Peak 

Frequency Period 




SUL-5, 7 A 












2001 


Order File Slip 


yellow 


Order File 










SUE^7 




j 








2002 


■ Dealer File Slip 


orange 


Dealer File ! 




• i 

! 


i 

i 




sul-7, m 




J 








2003 


i Cataloging Slip 


green 


Order File 1 






; i 


! SUL-7. 7 A 


< 


j 




* 




2004 


; Requestor Notice 


pink 


Order File i 




, i 

i 


| * 

i j 


1 


■ sul-7, '/a ‘ 




Order File or 






• 


2005 ! 


! Fund File Slip! 


blue 


Fund File i 








f 


i • ; i i : 

i i i • i . ! ; 




SUL-25, 25A : 


white 


1 




; i 


i y 


2006 


Book Requisition 


Requestor 


Order File 1 






i j 

i 



~\ 



I 



2007 

2008 



*S0C=7 

De aler Report 



whi tel 1 arrives wi th ■ 

Dealer 'material, is not 



I 



-r 



Invoice 



Dealer 



I Paid kept 
! Invoice Fi le 



_L. 



| SUL-80 : 

2009 [ Serial Slip ! 


UrcrerTTTe and/pr j \ 

Serial Payment! \ 

File J , : . - . 


1 ^ 


. j . ! l 


| SUL-5 | Resources 

2010 | Search & Quote 'Development 


Search & Quote! j 

File j i i 


j Dealer supported Abel or 
2011 • Process Slios \ Stacev 


Appropriate •! j C* 

File i 1 ! 


1 

* 

t 




‘ i i * 

* * * t 

| ; i 




t 

t 




■ n 

i 


[ L 




* - T"' ~ ~ 

| 


i 




i 

1 


i 

L_ 




1 | 

• • 1 


i 

| 






i 

- \ 

— 1 — - 


1 

1 

i 

f 




: i 


1 


. i 

i 


i 

• 

! • 


i 

i 

i 




i 




! ! 



Q — 
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Order Department 



2006 



! 



i 

( 

l 



{ 



i 

I 




j 

i 

I 

( 




ORGANIZATION FORM NUMBER 

SUL-25. 25A 

FORM NAME 

Book Requisition Order Card 



1 LG eard Z 1966c 



’j Author Conference on Technical Information Center 
• ! Administration. 3d, Philadelphia, 1966 

'j Title TICA 3. Edited by Arthur W. Elias 

j i • 


addsd - ed~ 
Z675 
T3C6 
1963 

(Comp.Sci)- 


i Edition J Place... Publisher 

.j | New York Spartan Books 


1 Date of Publication No. Voli. 

•j 1967 vii,13 


1 Series 

5 p. (Drexel information science 
series, v. l») 


i No. Cop. Price 

! 7.00 



i Req. by flruijULrd 


Order From: • 


j 


Other Info.: 


i p fr ». t 


;• 1 


i , 






• ! 

_ i 






1 AtM NKA ..006 




\ ' 




* 5 b* 1 ** CompeSci* 


Cat.: 1 


! ; 


Item: 


1 — — r* 


— p- 

» _■* 


— f- — 


. * 



EXPLANATION: 



The SUL-25A Is used for requesting books (the originator 
keeps a carbon)* 

The SUL-25 form Is used for requesting books and is also 
used as the basis for annotating the. results of searching and 
establishing* 
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ORDER DEPARTMENT FILE INVENTORY 

ORGANIZATION 



) 



Peak { 

No. File Name File Content Seq.i Volume ! 

Library ot Congress Main 6/30 

4001 LC Title II Catalog Cards Entry! 12/31. 

4002 Order Process slips for ■ „ ** . 

twi order on or( ^ er an § received Entry 


i Average- Access . Peak 

Volume Frequency Period 

\ * . \ • 

Lho.uxly !._M-f . 

iT), 000 Morning 

in process hourly M-F 


files | j , 

.. . 1 1 1 


t 


4003 : Dealer uettier ^ps ror \ F.o. 

on-order and received No. 




See > : 4.5 

detail \ hourly M-F 


; , i lie si 






! 


TTOc! slips for 

4004 ; Fund expensive acquisitior 


i Fund; 


1 


— 270Y7D p " - ~ f 

since 9/66 j daily ; Aug. 31 


and oraers committed 
'to restricted funds 


1 


I 

i 


t : 

1 j 


i 1 r 

j ! 

* » 




j 


l ^ 


4005 : Cancellation 


Main 

Entry 


• - •• 


2, 100 j ~**“ 

Der vear 


t , 

1 i 




! 


, ueaier supplied 

n 4006 j University Press process slips for j 


j 


! 


1,200 1 i 

i since 9/66 t weekly j M-F 


) ’ UfifV Pifess“MaterIal 

1 




! 

i * 


1 i i 


Process sups tor 
4007 Approval ’items received and 


TJ i 

Dealdr 


! 1,800 ; ! 
since 9/66 i daily i M-F 


. retained on approval 


Main; 

Entry 


1 : 

: i 


| 50 


i 

i 

♦ 


AOOft ! Outstanding Requests and out- 

wwo i Overseas Order Standing overseas 


I 


| random ; M-F 


i i orders 

\ j 


J 


n . — 

! i i 

L L . ! 


; Keceipt without ; Fund slips for 
4009 j Invoice j material received 


bealerj I 200 ! daily ’.M-F 


jwithout invoice i • 1 

* ! i j ! 


1 

1 

? ■ t 

• 1 


; invoice without j Invoices received j { 

4010 Receipt prior to material .Dealer 


150 j daily ! M-F 


v receipt 


i 1 


1 1 

1 ) 

i .! _ _ ! _____ 


AMI Re flil??£2 r i.Pink process slip ; _ i j . ' I 

4011 j Notice to be sent to re- ; Requestor J j daily i F 



questor on receipt” i 
' of book ! 



) 

O 
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Order Dena r tment 
ORGANIZATION 



4002 

FILE NUMBER 



FILE NAME Order File 

CONTENT Purchase order pro cess slips 
Sequence Alpha by main entry 
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Description and Use: 

The Order file serves as a central storage and reference 
location for all purchase orders in process, and for material 
received, not yet cataloged. 

When a procurement order is placed, the purchase information, 
contained on process slips, is filed in the Order file. The slips 
are periodically maintained throughout the activity cycle of an 
order, VJhen the status of an order changes the change is reflected 
in the file. Cancelled orders are purged from the file. 

There are several order categories; thus, in order to ease 
the accessing process, each order is flagged according to type 
or status. 

Items flagged in red indicate: 

1) Monograph orders not yet received, or 

2) Multi- volume sets, other than continuation material, which 
have been partially received, 

A blue flag indexes a standing order of a complete work or 
series. Also, a blue flag replaces a red for a partially filled 
order when the committed dollars are spent. 

Yellow and green flags identify "On Approval" orders for 
which purchase orders are not prepared. These file entries 
usually consist of an LC Card and a request slip. 

When the order material is received in full the various 
flags are removed, but a slip, stamped with the date of receipt, 
remains in the file. 

When orders are cancelled the process slips are transferred 
to the Cancellation File, 

Orders for the Meyer Undergraduate Library are maintained 
in a separate file but the same filing system is employed. 
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Order , Departme nt 
ORGANIZATION 



4002 

FILE NUMBER 



1. FILE NAME 

2. SEQUENCE 
3* RECORDS 

4* INPUTS 

5. ACCESS TO F 

6, MAINTENANCE 



0 




“ Describe as needed: Order File 



- Main entry - usually author 



- No. in File: 4.700 in p roce ss 

average maximum minimum 



Retention Period: until order ca tal oged 

in this file after removal from file 



Average No. ^ . _ , . ^ 

p er ° see statistical survey results 

day, vzeek, month, etc. additions changes deletions 
Source Document for Inputs: 



,LE - x and x 

random cyclic other - describe 

„ - see survey results 

Frequency of reference: per 

number hr ., day, week, etc . 



- Describe: Additions are made primarily when purchase 
Additions orders are generated and non P.0, types 
of material are received. 



Changes - Changes are made to reflect changes in 
the status of an order (receipt). 



Deletions-Purging sometimes occurs after cataloging. 
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6.7 Project Management Standards 
(referred to in subsection 2.2.2) 

1. System Development Process 

2. Project Standards (DS.0G1) 

3* Task Control Sheet (DS.002) 

(The standard given here is 
for a more recent version of 
Figure 2 on page 20.) 

4. Schedule Forms SB-3, SB-4, 
and SB-5 (DS.009) 
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SYSTEM D E V E L 0 P M E H T PHASE ACTIVITIES 



© 

SI 

?! 

© 



© 

li 

i 

© 



© 



H 

< 

x 

:* 




INSTALLATION 


0) TRAINING 

(secondary 
personnel ) 


2) CUTOVER — 
parallel 
operat ion 

3) WI 5 If BOOK 

5) Prepare final 
narrative 


« 

1 <H 
CO ka U 

U] 0 CO 

U CM M 

l-a ka M 

U, go 

Or M 

H UI 

X ka 

UJ g 3 

> -C U 

Z M C 

0 a n 

u u s 


FILES; PERFORMANCE 
STATISTICS, SUPPORT 
PLAN, PROJECT 
HISTORY, WISHB00K 
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SPIRES/BALLOTS PROJECT 
DOCUMENTATION STANDARD DS.001 


.Section 


Page 1 of 2 


Date 5/6 /N7C0 )R( J 


TITLE: PROJECT STANDARDS 



PURPOSE. Standards are formulated to advise project staff 
of methods, forms, procedures and schedules which must be 
adherred to in completing tasks. There are three general 
types of standards, ADMINISTRATIVE STANDARDS, DOCUMENTATION 
STANDARDS, AND < TECHN I CAL STANDARDS. (1) Administrative 
Standards originate with project management. They encompass 
matters which arc determined by the project management, such 
as, long-range plans, schedules, and task lists. In addition, 
other material relating to overall development policy may be 
issued as an Administrative Standard. (2) Documentation 
Standards are primarily formulated by the Documentation Office 
and approved by project management. They include standards for 
writing, recording, revising and disseminating records of 
project activity. Examples of Documentation Standards are 
forms and instructions for completing forms. (3) Technical 
Standards are primarily formulated by the technical section 
of the project staff and are approved by management. They 
include standards relating to coding, testing and debugging 
programs as well as instructions for the use and maintenance 
\ of program modules. 

^ STANDARDS DOCUMENTATION. Standards are initially issued in 
draft form for review. When a Standard has been approved a 
data set is created by the documentation staff using the 
following naming convention: 



DUG.DOC.XS.HNN 



Where x is either A, 0 or T standing for Administrative 
Documentation or Technical Standard. NNN refers to the ' 
sequence number for the standard which will be in the 
range 001 - 999. A hard copy of the Standard is prepared 
6n the formatted form SB-2. 

» 

DISTRIBUTION. After an original hard copy of the Standard 
has_been made two copies are xeroxed and each is routed to 
• half of the staff for immediate notification. Enough copies 
are then xeroxed for each staff member's Project Control 
Notebook. These are put in the appropriate section of each 
notebook by the secretarial staff. About ten extra copies 
are then xeroxed and returned to the Documentation Office. 

These are put in a folder in the Standards file. Additional 
copies of the standard may be secured on request by any 
project staff member, ) 

l 

REVISION. Proposed revisions to a Standard are forwarded to 
the Documentation Office. If approved, a revised standard is 
issued with the revision box checked on the S/B-2. Distribution 
follows the above procedure. I 

O I 
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SPIRES/BALLOTS PROJECT 




DOCUMENTATION STANDARD DS.OG1 



Spc t ion 

Page 2 of 2 

Date 5/7/7CN( )R( 



TITLE: PROJECT STANDARDS 



INDEX. Two Indexes, to-* standards are produced and maintained 
by the Documentation Office. A Standard Number index and an 
Alphabetical Title index. These indexes are placed in the 
front of the Standards section of the Project Control Notebook. 
They are revised periodically. 
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SPIRES/BALLOTS PROJECT 
DOCUMENTATION STANDARD DS.002 


Section 


Page 1 of 4 


New ( ) Rev(x) 


Da te ll/G/70 


TITLE: TASK CONTROL SHEET FORM l/F-Kll/70) Supercedes S/B-H4/70) 



INTRODUCTI ON: This standard describes the use of the Task Control 

Sheet (TCS). A Task Control Sheet documents and communicates a task 
assignment/ description and schedule. It permits managers and project 
staff to coordinate tasks and allocate time for task effort. The 
information on a completed Task Control Sheet is used to evaluate task 
performance and analyze problems for future Improvement. 

When a task is assigned some sections of a TCS are filled out by the 
person who assigns the task/ and other sections are filled out by the 
secretarial staff who also handle copying anc distribution. When a 
task is completed sections not filled out at task assignment are 
filled out and the secretarial staff handles copying/ distribution/ 
and storage of additional copies of task documentation for future 
demand. The following paragraphs describe the use of the TCS when the 
task is assigned (1.0) and when the task is completed (2.0). 

1.0 TASK ASSIGNMENT 

1.1 Analysis/Design Staff Responsibilities 

The following sections of the TCS are filled out by the person who 
assigns the task (assigner) or by him and the person to whom the task 
is assigned (assignee). 



2. TASK TITLE: Provide a short/ three or four 
easily transferred to a schedule form (S/B-3/ 



word/ title 
S/B-5). 



which can be 



3. ASSIGNMENT: Provide names or initials of all persons assigned and 
the names of all users who will contribute to or approve the task 
result. After the TCS is typed the assignee(s) initials and dates 3A/ 
the assigner initials and dates 3B/ and the user initials and dates 
3C. Users initials may be inserted by the assigner wi th the user's 
verbal approva 1 . 



O - 

ERIC 



4A. TASK PERFORMANCE (Scheduled): Supply the starting date, 

completion date and approximate hours the task requires. The assigner 
is responsible for the information is this section. 

5. TASK DESCRIPTION: Give a full description of the task. 

6A. DOCUMENTATION REQUIRED: Describe what is to be included in the 
documentation/ such as a sample output/ or Job Control Language state- 
ments. Indicate the audience or use to be made of the documentation 
where this might be helpful. Estimate number of pages required if 
this is possible. 

7. I NTERFACES/CONTSTRA I NTS : Indicate previous task documentation that 
might help in performing this task/ staff members with special 

319 
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SPIRES/BALLOTS PROJECT 


Section | 




DOCUMENTATION STANDARD DS.002 


Page 2 of 4 


) 


New ( ) R ev ( X) 






Date 11/6/70 j 



TITLE: 

know I 

proj e 
whi ch 



TASK CONTROL SHEET FORM l/F-l(ll/70) Supercedes S/P.-H4/70) 



e d g e , or pr 1 n tea sources or 1 nrormafion. 
ct managment or users should be stated, 
policy questions should be directed. 



constraints iiii£i65e'dr" 
Indicate sources to 



W 



1A. PI STR ! RUT I ON (Task Assignment): List T1 Includes the 

analysis/design staff and the Principal Investigators. Add initials 
of "Other" such as users, library or Computation Center personnel who 
should be notified of a task. 

10. TASK AND PHASE: Insert Task area indicator and Phase letter. 

Task areas are B^BALLOTS, C=Common / D=Documentat Ion, and S=SPIRES. 
Phases are A=Prel iminary analysis, B=Detailed analysis, C=General 
design, D=Detailed design, E=l mpl ementat i on, and F= I nsta 1 1 a t i on. The 
task number is inserted by a member of the secretarial staff after the 
task area indicator and is taken from a task number log. 

1.2 Task Control Sheet Typing 

After he prepares a handwritten copy of the TCS, the 
assigner sends it to be typed and returned for proofing. The The 
proofed copy is initialed by the assigner, assignee(s) and user(s) in 
section 3 and sent to the secretarial staff to be prepared for 
distribution. 

1.3 Secretarial Staff Responsibilities 

When a typed TCS with initials in section 3 is received the following 
sections are completed on the typed original. 



9. COHiLET I OH 
section 4A. 



DATE: copy this directly from the "Completion Date" in 



10. TASK NO.: Take the next task number 
insert it here. Most task numbers have 
he inserted for numbers below 100, e.g. 



from the task number log and 
three characters and zeros may 
008, 053 etc. Subtasks are 



identified by decimal point 
numbering is usually put on 



task numbers, e« 
the form by the 



g. S. 008. 01. 
assigner. 



Subtask 



11. PAGE: Insert page number. 



The number of 
DISTRIBUTION. 



copies and distribution is determined by looking at 1A 
The original is always sent to Documentation. 



2.0 TASK COMPLETION 

2.1 Analysis/Design Staff Responsibilities 

When a task is completed to the satisfaction of the assigner, his copy 
of the TCS is stamped and initialed in the area below section 9 at the 
top of the page. The following sections are completed before 



O 

ERIC- 
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SPIRES/BALLOTS PROJECT 
DOCUMENTATION STANDARD DS.002 


Section 


Page 3 of i, 


New ( ) Rev (X) 


Date 11/6/70 


‘TITLE: TASK CONTROL SHEET FORM l/F-Kll/70) Supercedes S/B-K4/70) 



forwarding the task and documentation for distribution. 

4B. TASK PERFORMANCE (Actual): Insert the actual Start Date# 

Completion Date and Approximate Hours. If the Actual and Scheduled 
lines differ significantly explain this in section 8. 

6B. DOCUMENTATION (Data set information): If documentation is in data 
set form supply dsname# account and file(s). 

8, HINDSIGHT COMMENTS: Describe problems involved In completing the 
task and anything that might be useful In Improving the performance of 
future tasks. 

IB, 1C. DISTRIBUTION (Task Completion): Insert after "Other" in IB the 
initials of anyone you want to notify that the task is completed. 
Frequently this will be the same as the "Other" group in 1A. After 
"Other" in 1C insert initials of anyone you want to receive a copy of 
the full task documentation. 



After completing these sections on the assigners copy of the TCS# 
is sent to the secretarial staff with an original of the final 
documentat i on. 



it 



2.2 Secretarial Staff Responsibilities 

When a stamped copy of a TCS with attached documentation is received# 
xerox and distribute as indicated in IB and 1C. The copy with the red 
stamp on it is always sent to Documentation with the original 
documentation. Five extra copies of the TCS and documentation are 
made and kept in a "TASKS COMPLETED" file. All requests for 
additional copies of a task must be approved by the Documentation 
Office. 

3.0 TASK DOCUMENTATION REQUEST 

If you receive a TCS and you needthe full documentation^ initial 
section 12 "Documentation needed" and send it to the Documentation 
Office. The TCS will be returned with a copy of the documentation. 
The Documentation Office will keep a record of all requests for 
documentation. 

4.0 CANCELLED TASKS 

4.1 Analysis/Design Staff Responsibilities 

Tasks may be cancelled only by the assigner. The reasons for 
cancellation are written in section 8. HINDSIGHT COMMENTS and IB. and 
1C. DISTRIBUTION are filled in. The TCS is sent to the secretarial 
staff. 



O 
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S/B-2-(4/70) 



| VI « 



DISTRIBUTION 

A) Task. Assignment : (TCS only) 
List: T1 Other. 



TASK CONTROL SHEET (TCS) 
2 



3) Tns>L_ Conplet i on : (TCS only) 
List: T2 Other 



C) Task Completion ; (TCS &doc.) 
List: T3 Other 



Task Completion Date 



10 



Task No, 



Phase 



11 Page 

12 



.of. 



Documentation 
Needed 



2 . 

3 



TASK TITLE: 



A) PERSON(S) ASSIGNED: 

B) ASSIGNED BY: 

C) USER: 



-INITIALS 

-INITIALS 

-INITIALS 



.DATE:. 
-DATE : . 
. DATE : - 



TASK PERFORMANCE: 

A) SCHEDULED: 

B) ACTUAL: 



START DATE 



COMPLETION DATE 



APPROX HRS. 



TASK DESCRIPTION: 



6 


A) DOCUMENTATION REQUIRED: 










B) DSNAME: 


ACCOUNT: 


FILE: 




1 


INTERFACES/ CONSTRAINTS : 


8_ 

C 


HINDSIGHT COMMENTS; 

► 
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TASK CONTROL SHEET (TCS) 



) 



DISTRIBUTION 

A) Task Assignment : (.TCS only) 
List: T1 Othe r p * Weber_ 



B) 

C) 



Task Completion : 
List: T2 Other 



(TCS only) 



Task Completion : ( TCS & doc • ) 
List: T3 Other 



Task Completion Date 


10 


Task No. 


Phase 


8/10/70 




C.012 


B 




11 


Page J 


of. J . 



12 



Documentation 
Needed 



2 . 

3 



TASK TITLE: General Recovery Specifications 



PERSON(S) ASSIGNED: 


W. Kiefer 


TNTTTAT.S: 


VJ ft 


Bj&TE: 


7/8/70 


ASSTrtiran BY • 


J. Schroeder 


_• TNTTT AT.S ; 




PA'I'E; , 


7/8/70 


USER: E«B_. Parker, 


D.C. Weber 


INITIALS : .2 


£ -- 


DATE:- 


7/9/70 i 



A) 

B) 

C) 



TASK. PERFORMANCE : 

A) SCHEDULED : 

B) ACTUAL: 



START DATE 
7/12/70 



COMPLETION DATE 
8/10/70 



APPROX HRS. 
72 



TASK DESCRIPTION: 

1. Survey the literature, and derive a list of possible failure conditions. 

2. Study implementation concepts used on the Campus Facility System, and 
any others you consider applicable. 

3* For SYSTEM RECOVERY (to include 'soft crash', Data Base integrity, 

partial system recovery with operator intervention, and system recovery 
w/o operator intervention; in the order specified) investigate feasibilities 
for each error condition ennumerated in Step 1. 

Conceptualize testing techniques that will allow simulations of the 
various error conditions during implementation and check-out. 

For Data Base recovery, investigate 

a. Reconstruction of Data Base and indexes from a prior dump and 
the transaction log. 

b. ’ Partial reconstruction of indexes for specific records w/o 
reference to a log tape. 

List design concepts to facilitate 3 and 5 above. 

Conduct a staff conference to gather comments. 



4 . 



5 . 



6 . 

7. 



A) DOCUMENTATION REQUIRED: Write a paper to document your findings. Most of 

it should be understandable to the non- technical reader. 



B) DSNAME: 



ACCOUNT: 



FILE: 



INTERFACES/CONSTRAINTS : 


James Moore, Campus Facility System Group 
SLAG Facility 

O/S SER Modules (MVT, PLM and microfiche) 




HINDSIGHT COMMENTS : 
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DISTRIBUTION 

A) Task Ass i gnment : (TCS only) 
List: T1 Ot.hp r D » Weber 

B) 



TASK CONTROL SHEET (TCS) 

1 



List: T2 Other. 



(TCS only) 
D.Wehcr 



C) Task Compl e tion : (TCS &doc.) 
List: T3 Other 



Task Completion Date 
8/10/70 



10 



COMPLETED 



xm 






yo 



»w« n 



) i*. 



11 

12 



Task No. 
C.0I2 


Phase 

B 


Page. 1. ,_of_J 



Documentation j 
Needed . 



TASK TITLE: General Recovery Specifications 



A) 

B) 

C) 



PERSONS ) ASSIGNED: W. Kiefer 

ASSIGNED BY: J. Schroedc 

USER : E.B» Parker. D . C. Weber 



.INITI 

:INITI> 

-INITlJ 



LS: 

LS: 



y> K 



£ 



.DATE : 



< 70 



.LS:if-3\0 



-DATE: WEElSL 

.DATE: — l/SJJSL 



TASK PERFORMANCE: 

A) SCHEDULED: 

B) ACTUAL: 



START DATE 
7/12/70 

7/12/70 



COKPLETIONi 
8/10/70 | 



DATE 



APPROX HRS. 
72 



8 / 14/70 






A 

J 



TASK DESCRIPTION: 

1* Survey the literature, and derive a list of possible failure conditions. 
Study implementation concepts used on the Campus Facility System, and 
any others you consider applicable. 

For SYSTEM RECOVERY (to include ’soft crash* , Data Base integrity, 



2 . 

3. 



4. 

5. 



6 . 

7. 



partial system recovery with operator intervention, and system recovery 
w/o operator intervention; in the order specified) investigate feasibilities 
for each error condition ennumerated in Step 1. 

Conceptualize testing techniques that will allow simulations of the 
various error conditions during implementation and check-out. 

For Data Base recovery, investigate 

a. Reconstruction of Data Base and indexes from a prior dump and 
the transaction log* 

b. * Partial reconstruction of indexes for specific records w/g 

reference to a log tape. ° 

List design concepts to facilitate 3 and 5 above* 

Conduct a staff conference to gather comments* 



A) DOCUMENTATION REQUIRED: Write a paper to document your findings. Most of 

it should be understandable to the non-technical reader. 



B) DSNAME: WK. RECOVERY 



ACCOUNT: FS31 



FILE: filef and h 



INTERFACES / CONSTRAINTS : James Moore, Campus Facility System Group 

SLAC Facility 

• 0/S SER Modules (MVT, PLM and microfiche) 



fi HINDSIGHT COMMENTS: 

O 




Clerical overload held up task completion several days. 
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TITLE: 



TASK NO, 


TASK NAME: 
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LARCH 
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SPIRES/BALLOTS SCHEDULE - MARCH TO AUGUST 1970 



, c 



BY: 

DATE: 

REV. DATE: 





_L 


ARCH 


APRI L 


MAY 
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JUNE 


JULY 


AUGUST i 


6 
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27 


3 


10 


17 
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